--- Log opened Sat Jan 30 00:00:30 2021 00:39 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 00:39 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 00:40 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 00:40 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation 00:50 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 00:51 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 01:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 01:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection] 01:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 01:40 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation 01:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 03:10 -!- Aaronvan_ is now known as AaronvanW 04:00 -!- rdymac [uid31665@gateway/web/irccloud.com/x-cstenwhiusuuzfrd] has joined ##taproot-activation 05:58 < michaelfolkson> To be clear on some terminology. BIP 8 (and BIP 9 and revised BIP 8) are miner activated soft forks. Ideally we want miners to activate soft forks that have community consensus because user activated soft forks (BIP 148, 149) have additional risks (if not risks then at least possible disruption and uncertainty) that aren't present if miners cleanly activate 06:00 < michaelfolkson> The happy path with revised BIP 8 is that miners signal positively for Taproot activation during the MUST_SIGNAL phase 06:02 < michaelfolkson> If they do it moves to LOCKED_IN phase 06:12 < michaelfolkson> I'm a little bit hazy on the transition between the STARTED phase and the MUST_SIGNAL phase 06:18 < michaelfolkson> If one says they are against UASF (or that stumbling mechanisms should be inserted into the code for making UASFs harder) they are essentially saying that if miners refuse to activate a soft fork (with community consensus) forever it should never be activated? 06:20 < michaelfolkson> I don't get that. In Matt's Modern Soft Fork Activation design it had "a simple command-line/bitcoin.conf parameter which was supported since the original deployment release would enable users to opt into a BIP 8 deployment" 06:20 < michaelfolkson> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html 06:21 < michaelfolkson> Is that not a user activated soft fork as a last resort? 06:33 < michaelfolkson> I don't know what that means. Users opting into a miner activated soft fork mechanism (BIP 8) 06:45 < michaelfolkson> I think I get it. Revised BIP 8 isn't *entirely* a miner activated soft fork, more a mixture of a miner activated soft fork and a user activated soft fork 06:46 < michaelfolkson> Users set lockinontimeout=true 07:16 < luke-jr> michaelfolkson: UASFs do not have any more risk than MASFs; the difference is speed 07:17 < luke-jr> MASFs can activate *faster* than a comparable UASF 07:18 < luke-jr> hence setting one date range for miner activation, with a hard fallback time for user-activation 07:26 < michaelfolkson> Listening to Andreas on Let's Talk Bitcoin back in 2017 07:27 < michaelfolkson> "It stands a pretty good chance of causing a rift in the network. UASF also has a chance to cause a rift in the network, especially if miners decide to attack the minority chain which would be another escalation." 07:27 < michaelfolkson> Defining UASF as BIP 148, 149. You disagree? 07:29 < michaelfolkson> You have to incorporate miner reactions as well as lack of certainty with regards to user actions into your assessment of risk 07:32 < michaelfolkson> I'll repeat again that I think UASF (defined as BIP 148, 149) has to be an option if all else fails. But it is riskier. I don't know how one can claim it isn't. 07:34 < luke-jr> michaelfolkson: yes, I disagree 07:35 < luke-jr> miners can attack the network even without a softfork 07:36 < luke-jr> the only way it's "riskier" is if you consider miners getting mad they were left out and attacking because of that, as the risk 07:36 < luke-jr> but that's silly IMO; would we accomidate any miner demands because we don't want them to attack? 07:37 < michaelfolkson> They can attack the network at any point, right. But under normal conditions they aren't worried about a coordinated effort to reject their blocks 07:37 < luke-jr> it's no different than rejecting their invalid blocks now 07:37 < luke-jr> nobody told them to make invalid blocks 07:38 < michaelfolkson> Assuming you know for certain what consensus is on what is valid and what is invalid. 07:38 < luke-jr> a coordinated effort to reject invalid blocks is part of Bitcoin 07:38 < luke-jr> if you don't, there shouldn't be a softfork deploymetn at all 07:38 < luke-jr> neither MASF nor UASF 07:39 < michaelfolkson> Ok so why not do BIP 148 straight out the gate this time with Taproot? If it isn't riskier and we'd rather give that power to users rather than relying on miners? 07:39 < michaelfolkson> There has to be a downside to doing that. And I would agree that is because it is higher risk 07:40 < michaelfolkson> *I would argue 07:42 < michaelfolkson> (I also want to reiterate that with my limited knowledge of 2017 it seems to me higher risk options should have been on the table given the circumstances. I am not arguing against what happened in 2017) 07:52 < luke-jr> michaelfolkson: we should absolutely set lockinontimeout out the gate 07:52 < luke-jr> if you mean skip the MASF part, then the reason is that people would prefer Taproot sooner 07:59 < michaelfolkson> Because in the happy path Taproot gets activated quicker with revised BIP 8 than it would with BIP 148 08:00 < michaelfolkson> Ok 08:00 < michaelfolkson> This is hard for someone who wasn't looking at this stuff in 2017 :) 08:10 < luke-jr> well, BIP148 was just a hacked-in lockinontimeout for BIP9 08:20 < aj> luke-jr: UASF has the risk when miners are careless and aren't running recent software, not just if they're angry and actively decide to mine invalid things 08:22 < aj> luke-jr: (the risk being that potentially large numbers of pools/miners might be out of date in that way, allowing someone to trigger long chains of will-be-reorged blocks that will be seen as valid by any users who also haven't upgraded) 08:36 < luke-jr> aj: that'd be an issue no matter which activation is used 08:39 < luke-jr> and also why UASFs are slower ;) 08:53 < aj> MASF's don't activate unless miners take positive action, and if a vast majority of miners get it right, users who haven't upgraded don't have a significant risk 08:53 < aj> there's still a problem if miners are running actively broken things like indefinite spy-mining with no validation, though 09:00 < luke-jr> which they are 09:00 < luke-jr> but unless it's some reckless short window of time, a year or longer for a UASF gives miners plenty of time to update 09:26 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has joined ##taproot-activation 09:34 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Quit: liberliver] 11:41 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Ping timeout: 256 seconds] 11:43 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation 11:47 -!- ajonas_ [sid385278@gateway/web/irccloud.com/x-bgtpgwlcfpuidlxj] has quit [Read error: Connection reset by peer] 11:47 -!- ajonas_ [sid385278@gateway/web/irccloud.com/x-yqweceiohbatmvvw] has joined ##taproot-activation 12:06 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Ping timeout: 265 seconds] 12:09 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation 14:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 14:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation 16:25 < robert_spigler> Just trying to understand all points/sides before the meeting. Some questions I still have. 1) Why the Quiet(6m) between the attempted MASF and lockinontimeout=true section in the Modern Soft Fork Proposal? 16:28 < robert_spigler> 2) What are the arguments for/against mandatory miner signaling? (BIP 148 vs 149 sort of in terms of 2017) 16:33 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 16:36 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds] 16:39 -!- belcher_ is now known as belcher 16:50 < robert_spigler> What's up with Matt, he ok? 17:51 -!- felixweis [sid154231@gateway/web/irccloud.com/x-xnoihktppjcorqez] has quit [Ping timeout: 260 seconds] 17:53 -!- felixweis [sid154231@gateway/web/irccloud.com/x-sqzrqmsjedkmcfno] has joined ##taproot-activation 18:18 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection] 19:40 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Ping timeout: 268 seconds] 19:42 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined ##taproot-activation 20:12 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Read error: Connection reset by peer] 20:13 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation 20:18 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Read error: Connection reset by peer] 20:20 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation 20:24 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 20:25 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 22:54 < aj> robert_spigler: the "modern soft fork" thing requires manual action to enable to the user-enforced phase (setting a flag or upgrading the software to have it by default), but miners could still trigger activation as soon as the second phase starts -- the quiet period just gives time for users to change config/upgrade before any rule changes actually take effect 22:57 < aj> robert_spigler: mandatory signalling; pro: if you're part of a 5% minority trying to enforce a UASF, with mand.sig you'll see if everyone else doesn't care immediately because there's no signalling; w/o you'll only see your tx's are not being mined and maybe eventually one gets stolen, but that could take months or years; con: mandatory signalling is an easy way to force a chain split amongst 22:57 < aj> people enforcing/not-enforcing the new rules, if miners don't react with ~100% compliance like they did for bip148/bip91 23:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection] 23:49 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation --- Log closed Sun Jan 31 00:00:32 2021