--- Log opened Tue Jul 21 00:00:25 2020
--- Day changed Tue Jul 21 2020
00:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
01:08 -!- slivera [~slivera@103.231.88.10] has quit [Remote host closed the connection]
01:08 -!- slivera [~slivera@103.231.88.10] has joined ##taproot-activation
01:11 -!- somethingsomethi [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has joined ##taproot-activation
01:13 -!- rdymac [uid31665@gateway/web/irccloud.com/x-ijxbxakkgbtlxgqd] has joined ##taproot-activation
01:13 < somethingsomethi> Quick question: On the "see what happens" option, it now lists as a con that everyone needs to upgrade again in case it fails. Doesn't this also apply to the proposals with a discussion period? Because presumably, during the discussion period it would be decided what to do next, no?
01:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:27 < harding> somethingsomethi: I think that's a bit confusing.  For MSFA, I don't think it's clearly specified in Matt's email.  aj's bip-decthresh says, "Implementations should also allow users to override the default from conditional activation to guaranteed implementation, so that the soft fork rules can be enforced without needing to upgrade to a newer software version."  Is asking people running old implementations to add a line to
02:27 < harding> their bitcoin.conf a potentially significant con?  I don't know.
02:28 < zmnscpxj__> MSFA "Modern Soft Fork Activation" ; MASF "Miner Activated Soft Fork".
02:33 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
02:41 < somethingsomethi> If it's really just adding a line to a config file, it's not much of a burden to individual node operators, but I wonder if that could really be efficiently coordinated?
02:42 < aj> the modern-activation/decthresh timelines are really long so coordination doesn't have to be very efficient
02:43 < aj> conversely, bip148/bip91/whatever seemed to indicate coordination might be able to be done quickly?
02:43 < somethingsomethi> but ok, so the general idea in msfa & decthresh would be to deploy the entire sequence (first attempt, pause, second attempt) in one go, and then the discussion period would serve to decide if the second attempt needs to be modified or cancled instead?
02:44 < aj> yeah, sounds right
02:45 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
02:46 < somethingsomethi> I wonder if the discussion period could be skipped entirely in that case
02:47 < somethingsomethi> because a couple of months after the first period started and it becomes increasingly obvious it won't activate, people will start discussing anyways
02:48 < somethingsomethi> i.e. second half of the first period will more or less automatically turn into the discussion period
02:57 < harding> That sounds reasonable to me.
02:57 < harding> Maybe a DecTresh-Fast variant.
02:59 < harding> Though if you're still waiting two years or more for mandatory activation, shaving a year off of the timeline doesn't feel like much.
03:02 < somethingsomethi> btw, if the whole sequence is preprogrammed, then the non-commital pro for these two methods doesn't really apply, because you'd still have to do the uproot to prevent the second attempt from starting
03:10 < harding> somethingsomethi: if it's pre-programmed, yes, but not I think if it requires users change their configuration.
03:13 < harding> Oh, you're talking about an automatic sequence of BIP8(false)->BIP8(true).  I don't think that's what is being propoed; the first implementations would be BIP8(false); the later implementations would be BIP8(true).  It wouldn't be automated.
03:16 < harding> Edited to hopefully make that a bit clearer: https://gist.github.com/harding/dda66f5fd00611c0890bdfa70e28152d/revisions#diff-e0ff3461e7d6448c94069d2264c6e46f
03:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
03:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:25 -!- roconnor [~roconnor@host-192.252-163-181.dyn.295.ca] has quit [Ping timeout: 240 seconds]
03:53 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
03:57 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 258 seconds]
04:42 < somethingsomethi> ok, so in msfa and decthresh users will have to actively modify their configuration in order for the third stage to start?
04:45 < aj> somethingsomethi: normally they'd just upgrade and the new software, released after the first stage had ended, would have the defaults; modifying the config is there as an option so they can stay in consensus in case upgrading would be annoying for them for some reason
04:45 -!- jeremyrubin [~jr@2601:645:c200:f539:80dd:c5af:615d:d30c] has quit [Ping timeout: 260 seconds]
04:57 -!- somethingsomethi [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
05:01 -!- somethingsomethi [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has joined ##taproot-activation
05:02 < somethingsomethi> aj: Sure. But either way, some manual intervention will be necessary (otherwise, the first stage wouldn't be non-committal)
05:04 < somethingsomethi> (the new version with different defaults would also mean that Core has to align their releases to the proposal's timeline. Probably not a big deal, but maybe worth mentioning)
05:11 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has quit [Ping timeout: 240 seconds]
05:11 -!- roconnor [~roconnor@host-45-78-242-158.dyn.295.ca] has joined ##taproot-activation
05:11 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has joined ##taproot-activation
05:12 < aj> somethingsomethi: changing activation params goes in minor releases, which is easy to do as long as the timeframe isn't ridiculously tight
05:12 < fanquake> I think it's unlikely that we'd radically change our major release timeline from ~6monthly.
05:12 < fanquake> aj is correct that there is a lot more flexibility for minor releases
05:13 < roconnor> and backports are a thing too.
05:14 < fanquake> I'd love it if we could find a few more people to review / sanity-check backports.
05:25 < harding> I think we're just talking about a ~1 LOC change here, so backporting in that case should be trivial.
06:16 -!- slivera [~slivera@103.231.88.10] has quit [Remote host closed the connection]
06:19 -!- somethingsomethi [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
06:23 < harding> https://en.bitcoin.it/wiki/Taproot_activation_proposals
06:31 < aj> harding: i guess i see the "see what happens" thing as being on a different axis -- like, there's no reason we couldn't turn add "bip8(true,2 years)" onto "see what happens" and turn it into "modern soft fork activation"
06:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
06:33 < aj> harding: it's more "when do we decide to do lockinontimeout: as soon as someone installs the UASF client? (i think that's luke's preference?) after we've tried 12 months, but with the time frame pre-determined? (modern/matt) only after we've tried for 3 months and seen what happens? ("see what happens") "undecided" (all the ones with "chaos risk" as a con)
06:33 < aj> s/: as/?" as/
06:34 < harding> Basically you're saying that BIP8(false, ~2y) can be any of the other proposals that don't start with BIP8(true, -)?
06:35 <@moneyball> I only see one listed with chaos risk
06:36 < aj> oh, i was assuming "accelrate activation" for "gently discourage apathy" would have it too
06:36 < harding> Yeah, it probably should.  I'll add that.
06:37 < aj> harding: no i'm talking about bip8(false, 3m) ?
06:38  * harding re-reads
06:39 < harding> aj: I think what you're saying is what I was attempting to address by, "Columns with empty stages appear when no action is specified in advance (but any action with broad user support is still possible). "
06:40 < aj> harding: so bip8(false,3m) followed 2 months later by modern(0m,6m,24m) would be similar to doing modern(3m,9m,24m) from the start overall, but the difference is when decisions are made
06:40 < harding> Yeah.
06:42 < aj> likewise bip8(false,12m) then bip8(true,2 years) as independent things looks like modern() except for people who don't want to recompile/upgrade
06:42 < harding> I'll edit the extended description for "Let's see what happens" to try to make that clearer.
06:42 < aj> i guess i'm saying it's a different axis?
06:42 < aj> like there's one question of "when to decide what to do if miners prove unable to activate quickly"
06:43 < aj> and there's another question of "how to coordinate activation without relying on miners"
06:43 < aj> and "see what happens" is only remotely interesting to the former, not the latter?
06:46 < harding> I agree there's two degrees of freedom there.
06:46 < aj> \o/
06:46  * harding thinks about how to visualize that
06:49 < aj> i suppose bip8(false,3months) with a config flag allowing you to extend that to bip8(false,42months) would be a way to let people who upgrade for the 3m attempt but for whatever reason don't want to upgrade again later still enforce the results of a later flag day activation with mandatory signalling
06:59 < harding> I think perhaps any plan that lasts longer than about 6 months has a significant chance of being changed in situ via something like BIP148 or BIP91.
07:10 < harding> GIven that, I don't think there's that much difference between BIP8(false, 3m) and most of the other proposals.
07:12 < aj> harding: right, the theory being that then it doesn't matter which other proposal you like, we can get started on bip8(false,3m) "immediately"
07:14 < aj> harding: but it may be that the difference there is (ie, when we make the decision on what to do if miners aren't helpful) super important somehow
07:32 < harding> aj: I don't think I'm understanding your concern, sorry.
07:34 < harding> Is there something missing from the pros/cons of BIP8(false, 3m)?
07:36 < harding> Like, should it have a variation of "Chaos risk" because there could be bifurcation of the community responses to miner unhelpfulness, e.g. blue team wants BIP8(true, 2y), red team wants BIP8(true, 6m)?
07:39 < aj> harding: maybe the problem is i'm a blind man trying to describe an elephant? i just feel like there's a simpler/more fundamental way to describe the differences somewhere?
07:47 -!- adiabat [~adiabat@63.209.32.102] has joined ##taproot-activation
07:52 < harding> aj: I'd be happy if that's true and happy to help give it a try if you have any ideas.
07:52 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
07:56 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]
08:14 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-activation
09:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
09:16 -!- jeremyrubin [~jr@2601:645:c200:f539:c03f:40d9:1aa8:e444] has joined ##taproot-activation
09:27 < jeremyrubin> aj: I don't think there's any reason to do BIP8(false, 3m) and not BIP8(false, 2 years). The timing out at 3 months is only to 'preserve the bit'. You can even separate out concerns that you make calls to GBT signal default yes for 3 months, and then stop. But a longer window just means less upgrade/config file shuffling if another taproot activation wants to reuse that Bit
09:28 < jeremyrubin> We have plenty of bits so if the outcome is that we don't want taproot activated by that bit, we just need to use another bit which requires that bit be set false on lock in.
09:29 < roconnor> 4 years even!
09:29 < aj> jeremyrubin: "your homework's due tomorrow" "your homework's due in a month" -- which one do you start doing something about now?
09:30 < roconnor> BIP8(false) says your homework isn't due at all.
09:30 < aj> bip8(true) says it doesn't matter if you do your homework, everyone else will take care of it for you eventually
09:30 < roconnor> aj: that's definitely not true.
09:31 < roconnor> if miners ignore bip8(true) they will find themselves mining invalid blocks.
09:31 < jeremyrubin> roconnor: also not quite true; but I agree with you above
09:32 < jeremyrubin> roconnor: accepting standard txns to mempool only you might build on an invalid tip but your blocks won't themselves be invalid
09:32 < aj> roconnor: eh, it's been pretty inconsistent whether bip8(true) implies mandatory signalling on this channel
09:32 < roconnor> jeremyrubin: well if you don't start adding the manditory signalling bits, they certainly won't be valid.
09:32 < roconnor> aj: ah sorry, I didn't realize.
09:32 < jeremyrubin> roconnor: good point! forgot about that part.
09:33 < jeremyrubin> I think it has to imply mandatory signaling? You end the last state locked_in, which requires the next state signal right?
09:33 < jeremyrubin> Or is that up in the air...
09:33 < aj> jeremyrubin: the text of bip8 includes mandatory signalling
09:34 < aj> jeremyrubin: it could be changed to not do so; both modern activation and decthresh have flag day activation without mandatory signalling that we've been describing as bip8(true) with various timeframs for notational convenience
09:35 < roconnor> wouldn't manditory signalling be good for everyone?
09:35 < jeremyrubin> Why not do mandatory signaling at the end? Isn't that just asking for trouble?
09:35 < luke-jr> roconnor: yes
09:36 < roconnor> I can't see the advantage of being in a position where users are left unclear if they are all following the same rules or not.  That seems potentially disaterous.
09:36 < aj> jeremyrubin: depends. if there's any chance the flag day will fail, it's problematic for people who thought it wouldn't. if there's no chance the flag day activation will fail, it's fine
09:36 < roconnor> I mean manditory signaling isn't quite perfect, but it is really good.
09:37 < luke-jr> roconnor: most likely people just won't use Taproot at all if there's ambiguity, IMO
09:37 < aj> jeremyrubin: it also allows a flag day to bring along anyone who wasn't enforcing the flag day, if there are such people. (and the more such people there are, the more chance the flag day has of failing, so they're linked)
09:38 < harding> luke-jr: I think ambiguity will disapear over time as people store more and more funds in taproot UTXOs.
09:38 < luke-jr> harding: chicken and egg
09:38 < jeremyrubin> aj: I think it is more friendly to miners, less friendly to users, right?
09:39 < roconnor> Maybe it is best to split the network right away instead of waiting until some random undetermined point in time.
09:39 < jeremyrubin> Miners don't start mining invalid blocks at the end w/o mandatory signaling, unless there is an invalid tip
09:39 < aj> jeremyrubin: pretty much. i mildly prefer mandatory-signalling-at-95%-threshold i think. perhaps especially for any attempt where the flag day is being brought forward
09:40 < jeremyrubin> But for users? if a rule gets activated mandatory signaling is compatible with almost any concurrent bits based signaling config
09:40 < harding> luke-jr: not really; if 10,000 people all stick $100 in taproot outputs, that's a million dollars of evidence at a minimal/moderate per-participant risk.
09:44 < jeremyrubin> Uh... maybe we should add chaos risk to whichever proposals are depending on that method :p
09:45 < aj> eh, if you don't set the flag day until consensus is clear, and you set the flag day a couple years out, and enable it by default in all the software, there's not much chaos risk by the time the flag day rolls around
09:46 < jeremyrubin> What? You can accept invalid blocks...
09:46 < aj> now, if you want to add a "pre-requisites will never be met and nothing will ever happen" risk...
09:47 < aj> you only get chaos if your view of what's valid differs from what everyone else's view of what's valid
09:47 < jeremyrubin> which can happen as you'll accept invalid blocks if you don't enforce the rule when everyone else does
09:48 < aj> which you don't do, because you upgraded your software sometime in the last few years, and it was already updated for the flag day
09:48 < luke-jr> aj: softforks don't need consensus, and the same level of support is required for both lockinontimeout false and true
09:49 < harding> Why don't soft forks need consensus?
09:49 < zmnscpxj__> unaware nodes never notice your softfork
09:49 < luke-jr> harding: https://medium.com/incerto/the-most-intolerant-wins-the-dictatorship-of-the-small-minority-3f1f83ce4e15 for the extreme case
09:50 < luke-jr> wait, that's the wrong link I think
09:50 < luke-jr> (apparently the concept exists outside Bitcoin XD)
09:50 < luke-jr> https://medium.com/@alpalpalp/user-activated-soft-forks-and-the-intolerant-minority-a54e57869f57
09:50 < harding> zmnscpxj__: but then the unaware nodes don't enforce the rules and you can't be sure they'll help protect your money when some miner tries to steal it.
09:52 < zmnscpxj__> but to you, miners never stole that money: you would reject blocks that did so, and so to your view, they are not miners, just fancy space heaters
09:53 < zmnscpxj__> "As to others, like myself, I had been speaking prose all these years without knowing, drinking Kosher liquids without knowing they were Kosher liquids." <-- seems an appropriate quote
09:53 < zmnscpxj__> from the first link given by luke-jr
09:53 < harding> zmnscpxj__: the un-upgraded user won't reject blocks that break the rule.
09:54 < harding> Just like I won't reject eating something because it's not kosher.
09:54 < zmnscpxj__> yes.
09:55 < jeremyrubin> I think Luke's point is that a small enough sample of people keeping kosher has enough might to force the whole system kosher
09:55 < jeremyrubin> Especially for something like taproot, which is minimally invasive to miners
09:56 < zmnscpxj__> "large enough, but small sample" I think
09:56 < luke-jr> jeremyrubin: well, in the long run, we do need a supermajority enforcing
09:57 < harding> ^ that's the point I'm trying to make
09:57 < luke-jr> the intolerant minority concept is more about how a large enough minority can effectively achieve that
09:57 < luke-jr> (in certain conditions)
09:58 < luke-jr> in reality, Segwit had ~80% support, which was far more than sufficient to get 100% acceptance in the end
10:00 < luke-jr> anyway, point there was simply that we don't need consensus (100%)
10:29 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]
11:02 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-activation
11:22 -!- joerodgers [joerodgers@gateway/vpn/mullvad/joerodgers/x-62861712] has joined ##taproot-activation
12:35 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection]
12:36 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation
12:53 -!- _joerodgers [~joerodger@c-76-125-83-191.hsd1.ar.comcast.net] has joined ##taproot-activation
12:57 -!- joerodgers [joerodgers@gateway/vpn/mullvad/joerodgers/x-62861712] has quit [Ping timeout: 240 seconds]
13:24 -!- krvopije [~toni@185.106.109.144] has joined ##taproot-activation
13:24 -!- krvopije [~toni@185.106.109.144] has quit [Client Quit]
13:58 -!- brg444 [uid207215@gateway/web/irccloud.com/x-vavnljalqmywcmos] has joined ##taproot-activation
14:05 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
14:08 -!- mol_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
14:08 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
14:08 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
14:13 -!- joerodgers [~joerodger@141.98.255.152] has joined ##taproot-activation
14:16 -!- _joerodgers [~joerodger@c-76-125-83-191.hsd1.ar.comcast.net] has quit [Ping timeout: 260 seconds]
14:56 -!- slivera [~slivera@103.231.88.27] has joined ##taproot-activation
15:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
15:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
15:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
16:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
16:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
17:18 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
17:20 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
18:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
18:51 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has quit [Ping timeout: 240 seconds]
18:51 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has joined ##taproot-activation
18:57 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
18:57 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined ##taproot-activation
19:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]
19:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
19:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
21:43 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
21:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
22:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
22:27 -!- TechMiX [~TechMiX@ti0169q161-1541.bb.online.no] has left ##taproot-activation []
22:40 -!- fiatjaf [~fiatjaf@2804:7f2:2a83:3b59:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 256 seconds]
22:40 -!- fiatjaf [~fiatjaf@2804:7f2:2a83:3b59:ea40:f2ff:fe85:d2dc] has joined ##taproot-activation
22:44 -!- brg444 [uid207215@gateway/web/irccloud.com/x-vavnljalqmywcmos] has quit [Quit: Connection closed for inactivity]
22:59 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 256 seconds]
23:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
23:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
--- Log closed Wed Jul 22 00:00:27 2020