--- Log opened Thu Feb 11 00:00:26 2021
00:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
00:26 -!- jonatack [~jon@37.173.248.254] has quit [Ping timeout: 272 seconds]
00:30 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
00:30 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
01:00 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 272 seconds]
01:30 -!- rich [~rich@shindig.notmandatory.org] has quit [Ping timeout: 256 seconds]
01:31 -!- rich [~rich@shindig.notmandatory.org] has joined ##taproot-activation
01:31 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has quit [Ping timeout: 256 seconds]
01:32 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 272 seconds]
01:33 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined ##taproot-activation
01:38 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has joined ##taproot-activation
02:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:32 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##taproot-activation
02:50 -!- fiatjaf2 [~fiatjaf@2804:7f2:2a8c:9df7:ea40:f2ff:fe85:d2dc] has quit [Quit: WeeChat 2.9]
03:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
03:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:57 -!- jonatack [~jon@37.169.62.216] has joined ##taproot-activation
05:04 -!- belcher_ is now known as belcher
05:10 <@michaelfolkson> I'm listening to Matt Corallo on TFTC and I'll respond to some of his points here as I go through it. Feel free to also add your view if you have one. I don't think Matt is on the channel anymore which is unfortunate but regardless I want to cover his points
05:10 <@michaelfolkson> I'll get a transcript up soon too. Until then the link to the podcast is here https://anchor.fm/tales-from-the-crypt/episodes/228-UASFs--BIP-148--BIP-91--and-Taproot-Activation-with-Matt-Corallo-eq7cif
05:12 <@michaelfolkson> The first part is on history of SegWit, SegWit2x, UASF etc which I don't think is the most important part. I actually think he has some good points here but that is for the historians. I want to focus specifically on the lessons he takes for this Taproot activation
05:13 <@michaelfolkson> "Let’s just do it, we’ve got this thing, let’s just turn it on, the last UASF came on and activated in a few weeks, let’s just do it. We’ve got this. "
05:18 <@michaelfolkson> This Taproot activation channel was opened in July 2020. That is 6 months and discussion was going on for many months before that. Matt wrote this post on the mailing list on Modern Soft Fork Activation in January 2020. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
05:18 <@michaelfolkson> So we have been thinking about this as a community for at least a year. Maybe some people think that is not long enough but it is not fair to say we are just "doing this" overnight whether we decide on something in next week's meeting or not
05:19 <@michaelfolkson> "I think if our approach to changes is that we as a very small community on Twitter or whatever just ship code that turns on a soft fork whether the network is fully upgraded to it, whether we’ve actually made sure that we’ve talked to as broad a community as we can, that doesn’t set up Bitcoin for a win. "
05:21 <@michaelfolkson> Many people have reached out to multiple stakeholders. There is the taprootactivation.com website for mining pools. There is AJ's developer survey. There are these meetings that are open to all
05:22 <@michaelfolkson> There is a Telegram chat that has gathered feedback from users
05:24 <@michaelfolkson> Anyone has been free to reach out to whoever they want and come back with views, feedback, data. You are still able to today. If you think there are views that aren't being represented please reach out to them and come back.
05:25 <@michaelfolkson> I get the "broad community" point but at some point you need to review arguments and data and try to come to a decision. Personally I think a year plus is long enough. Some may disagree
05:26 <@michaelfolkson> "Developers shouldn’t be deciding these things."
05:28 <@michaelfolkson> At some point someone somewhere has to make a decision. That may be a developer that opens a PR in the Bitcoin Core codebase. That may be a maintainer that merges a PR. That may be a miner who decides to signal for Taproot. That may be a user to decides to run a certain software version. There are decisions all over the place. I am deciding to respond on this channel. That is a decision
05:30 <@michaelfolkson> Decisions at some point have to be made. All you can do is collect arguments and data from that "broad community" and then make a decision based on it. Sure you can try to pass the buck and the developers can say the miners should decide and the miners can say users should decide and users can say developers have the expertise and they should decide. All that happens with that is a decision never gets made
05:32 <@michaelfolkson> "How can someone who is just passively observing Bitcoin, maybe they care about Bitcoin but they probably don’t have the time to actively participate in the conversations on Twitter or Clubhouse or Reddit or what have you, how can they take away a message from that anything other than Bitcoin Core decides consensus and maybe a small group of users? "
05:34 <@michaelfolkson> They take away a message of various people spending hours/days of their time reaching out to as many people as possible for arguments and data. There is an evidence trail here. On these conversation logs, on taprootactivation.com, on AJ's developer survey. Again I'll repeat if you think something should have been done but hasn't been please suggest it or even better yet do it yourself
05:39 <@michaelfolkson> "Let’s just do it, we’ve got this thing, let’s just turn it on, the last UASF came on and activated in a few weeks, let’s just do it. We’ve got this. "
05:41 <@michaelfolkson> I guess the second point to answer is on rushing miners into signaling. At the moment we seem to be agreed on BIP 8(1 year). If we decide to set LOT to true miners will only have to activate after a year. A year to get ready to signal and activate is not rushed in my opinion.
05:43 <@michaelfolkson> Of course they can activate it earlier if they are ready. But if they aren't a year does not seem rushed to me
05:53 <@michaelfolkson> "I’ve seen a lot of people recently on Twitter and wherever talking about how basically UASF is good because it beats miners over the head and tells them they have no control"
05:55 <@michaelfolkson> Personally I don't use Twitter. I think the discussion here has been much more productive than it would be on Twitter.
06:04 -!- jonatack [~jon@37.169.62.216] has quit [Ping timeout: 240 seconds]
06:05 <@michaelfolkson> "enforcing these new rules by the time the flag day happens you can very easily end up in cases where you have forks"
06:12 <@michaelfolkson> I think this is where Matt participating in the discussion could really add value. I haven't been convinced this risk is any greater with LOT=true than it is for LOT=false. I actually have chain split discussions as arguments for LOT=true in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html namely T2 and T6. But personally I think this is the most important point to discuss and Matt's
06:12 <@michaelfolkson>  perspective would be valuable here
06:13 -!- jonatack [~jon@37.169.62.216] has joined ##taproot-activation
06:15 <@michaelfolkson> The higher level argument to this is that presumably the end state we all seek is that Taproot is activated at some point in time. If that is the end state we are working towards being able to tell everyone that we don't know when the activation will be but it will definitely be within a year offers clarity to all stakeholders. Compare this to a scenario where we set LOT=false, miners don't activate after 6 months and
06:15 <@michaelfolkson>  then we are scrabbling around for Core to release LOT=true, or someone else to release LOT=true or wait until the year is done. All chaos that can be avoided with near certainty with LOT=true
06:18 <@michaelfolkson> Using a rushed, chaotic UASF in 2017 as a reason not to do a measured 1 year long MASF with the so called UASF only kicking in at the end of that year I don't think is a fair comparison
06:48 -!- setpill [~setpill@unaffiliated/setpill] has joined ##taproot-activation
07:12 < nothingmuch> michaelfolkson: also, indecision *is* a decision. in my (addmittedly devil's advocate) arguments for LOT=false i think i failed to emphasize this
07:16 < nothingmuch> the thing that makes me genuinely more supportive of LOT=false is F3 precisely because that might settle the BIP 148 controversy, making the case for LOT=true stronger in the future
07:34 <@michaelfolkson> "People are saying we are just going to do it and we’re going to activate it and that’s just how it’s going to be. That to me sounds like New York Agreement, SegWit2x. It is a broader set of people, it was planned in public instead of in private, sure and that is great, that is an improvement, but it is still this discourse that sets Bitcoin up for not being this community that takes itself very seriously and is
07:34 <@michaelfolkson>  very careful."
07:37  * michaelfolkson shrugs
07:41 < setpill> You can always find bad arguments for why something is a bad idea.
07:42 < setpill> NYA/S2X was a hardfork attempt.
07:42 < setpill> Not same realm at all.
07:45 -!- CARO1 [~Cesar@2804:7f4:c298:c4ee:7c3a:c9c7:c1a3:9e77] has joined ##taproot-activation
07:47 -!- CARO2 [~Cesar@2804:7f4:c298:c4ee:2cdd:f958:bbb6:f453] has quit [Ping timeout: 246 seconds]
07:47 < belcher> i see NYA as a face-saving response to bip148
07:47 < belcher> they saw bip148 was happening and came up with NYA as a way to make it seem like they're going along with it
07:47 < belcher> so NYA is irrelevant
07:47 < belcher> (i havent listened to matt's podcast yet, just commenting here)
07:55 < nothingmuch> belcher: just the bip 91 part or the whole thing?
07:55 < belcher> what do you mean
07:55 < belcher> bip91 was the actual code the miners ran (created by someone who supported bip148, from what i saw the NYA people never wrote any code)
07:55 < nothingmuch> bip 91 seems like saving face, saving face by accelerating MASF before bip 148
07:56 < belcher> (any _good_ code, the segwit2x client famously had that off-by-one bug)
07:56 < nothingmuch> but the subsequent hard fork that was advocated was entirely incoherent, and i don't think saved face at all
07:57 < nothingmuch> even without the off by one, there was no logical argument for doing it that way apart from "light clients must upgrade" which was a tacit admission of a malicious attack on those clients
07:57 < belcher> yeah
07:57 < belcher> well as i keep coming back to, the environment back in 2017 was _totally_ different to today
07:57 < belcher> its set a bit of a precedent but in most ways its very different, people actually agree on all the important stuff now
07:58 < nothingmuch> also the technical nature of the soft fork... taproot is much easier to argue as being strictly non harmful
07:59 < belcher> there was also the asicboost point, lots of people had the view (including me) back then that UASF was crucial for bitcoins survival, that if segwit didnt happen then bitcoin would actually die because asicboost would centralize it to worthlessness
07:59 < belcher> while today you cant really say if this taproot activation fails then bitcoin fails... not least because we can always try activating it again
07:59  * belcher bbl
08:00 < nothingmuch> asicboost is why i personally prefer LOT=true, i am just not convinced enough people see it that way to make LOT=true a Schelling point
08:00 <@michaelfolkson> "Mining pools have even started signaling that they’re in favor of it and they’re ready for it so why are we having these debates?"
08:01 <@michaelfolkson> To me this is completely inconsistent to what he said previously. This sounds like we shouldn't have debates if you agree with me but year long debates aren't long enough if you disagree with me
08:02 < nothingmuch> i don't think it's inconsistent... if MASF goes through, then there's obviously no contention. only if it fails, some questions that don't seem settled yet become relevant
08:03 <@michaelfolkson> But earlier on he said "how can they take away a message from that anything other than Bitcoin Core decides consensus and maybe a small group of users"
08:04 <@michaelfolkson> It is ok if miners decide but it is not ok if Bitcoin Core and a small group of users decide?
08:05 <@michaelfolkson> "whether we’ve actually made sure that we’ve talked to as broad a community as we can"
08:05 <@michaelfolkson> One minute we haven't talked to a broad enough community. The next minute why are we having discussions, miners are happy with this
08:05 <@michaelfolkson> You can't have it both ways
08:10 < setpill> Segwit deployment was building something before there was (full) agreement to do it. NYA/S2X was agreeing to do a thing before building something viable.
08:12 < setpill> BIP148 was a hack on BIP9 to turn a MASF into a UASF. BIP91 was a hack on BIP148 *and* NYA/S2X to make the handshakers appear to have saved the day while also activating segwit.
08:12 < nothingmuch> michaelfolkson: fair
08:13 < setpill> Very complex situation all in all. Would be nice if we could avoid that complexity with taproot.
08:13 < setpill> LOT=true seems like the most straightforward path imo.
08:27 <@michaelfolkson> Right no hacks, no future decisions, no stress, no urgency if BIP 8(true,1 year) is agreed upon
08:58 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
09:00 < robert_spigler> michaelfolkson:  thanks for the great summary
09:00 < robert_spigler> setpill:  agree
09:01 < robert_spigler> It's a shame that Matt has stepped away from the discussion, and I've clearly missed what the history is there.  But I didn't hear any new arguments there for LOT=false that changed my mind
09:11 -!- jonatack [~jon@37.169.62.216] has quit [Read error: Connection reset by peer]
09:12 <@michaelfolkson> "I have taken some time off from some of those discussions because I got a little frustrated." Just got frustrated apparently
09:14 < robert_spigler> Makes sense
09:21 -!- jonatack [~jon@37.169.62.216] has joined ##taproot-activation
09:24 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
09:34 -!- jonatack [~jon@37.169.62.216] has quit [Ping timeout: 256 seconds]
10:08 -!- jonatack [~jon@37.169.62.216] has joined ##taproot-activation
10:27 < emzy> fwiw I'm not totaly against LOT=true but I consider not to run the code. I will keep my nodes on a version without activation code and wait.
10:28 < luke-jr> so we're back to "just trust the miners" straight and simple? :/
10:30 < emzy> I see it more as wait for miners. Where is the trust?
10:31 < emzy> Running an old version and not using taproot myseld sould be always safe.
10:35 < luke-jr> emzy: if your node isn't enforcing all the rules, you don't have a full node and are trusting miners to enforce the rules for you
10:37 < emzy> Only if I use taproot. Talking about this SF.
10:39 < emzy> I'm fine if I don't use taproot.
10:40 -!- jonatack [~jon@37.169.62.216] has quit [Read error: Connection reset by peer]
10:41 -!- jonatack [~jon@37.169.62.216] has joined ##taproot-activation
10:41 < luke-jr> emzy: no, even if you don't use taproot
10:41 < emzy> Also stop doing transactions in the LOT=true activation phase. If that will come up.
10:43 < emzy> luke-jr: so you say we all need to update to a new version to use Bitcoin?
10:43 < luke-jr> yes
10:43 < luke-jr> that's how every softfork is
10:43 < emzy> That would be bad, if true.
10:43 < luke-jr> that's why there's a full year notice
10:44 < emzy> Hm. Ok. you right.
10:44 < luke-jr> (in the case of MASF, less than a year notice, but the network as a whole is okay if an economic minority trust miners)
10:45 < emzy> Was thinking wrong. In the end we need all to enforce *all* rules.
10:45 < emzy> Ok. I will think more about it.
10:51 -!- jonatack [~jon@37.169.62.216] has quit [Ping timeout: 240 seconds]
10:52 -!- jonatack [~jon@37.169.62.216] has joined ##taproot-activation
10:52 -!- jonatack [~jon@37.169.62.216] has quit [Read error: Connection reset by peer]
11:01 -!- jonatack [~jon@37.173.153.89] has joined ##taproot-activation
12:54 -!- jonatack [~jon@37.173.153.89] has quit [Read error: Connection reset by peer]
12:54 -!- jonatack_ [~jon@37.173.153.89] has joined ##taproot-activation
12:58 < nothingmuch> emzy: even if you don't receive any funds after activation you are still exposed to risk by not enforcing because chainsplits are harmful to the ecosystem. if you receive anything after activation to a non taproot address the origin of any funds you receive might be non replayable (post activation coinbase outputs in history) or stealable by miners on non active chain (taproot outputs in
12:58 < nothingmuch> history)
13:00 < emzy> Yes, that was what I was missing.
13:04 < nothingmuch> (fwiw the post activation coinbase output thing is an oversimplification)
13:04 -!- jonatack_ [~jon@37.173.153.89] has quit [Quit: jonatack_]
13:06 < emzy> Yes. depends on UTXO history of the received funds.
13:34 -!- jonatack [~jon@37.173.153.89] has joined ##taproot-activation
13:41 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined ##taproot-activation
14:41 -!- felixweis [sid154231@gateway/web/irccloud.com/x-ntdyaxjwaufomstj] has quit [Read error: Connection reset by peer]
14:41 -!- wangchun_ [sid444603@gateway/web/irccloud.com/x-xznnrtbggxdjkjro] has quit [Read error: Connection reset by peer]
14:41 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-fnnnbfkbileowsih] has quit [Read error: Connection reset by peer]
14:41 -!- felixweis [sid154231@gateway/web/irccloud.com/x-uxvkkvzinlkyxlvm] has joined ##taproot-activation
14:41 -!- wangchun_ [sid444603@gateway/web/irccloud.com/x-kszhzxjqgjaaiytr] has joined ##taproot-activation
14:41 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-ruscvhxdkxnvfepw] has joined ##taproot-activation
16:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
16:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
16:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds]
17:05 -!- jonatack [~jon@37.173.153.89] has quit [Ping timeout: 264 seconds]
17:58 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
18:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
18:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
18:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
19:00 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
19:02 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds]
20:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
21:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]
21:41 -!- naribia [6bb5bd25@107.181.189.37] has joined ##taproot-activation
21:42 -!- naribia [6bb5bd25@107.181.189.37] has quit [Client Quit]
23:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
23:38 -!- mol_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
23:38 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
23:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
--- Log closed Fri Feb 12 00:00:27 2021