--- Log opened Fri Feb 26 00:00:40 2021
00:53 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined ##taproot-activation
01:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
01:37 -!- fanquake [sid369002@gateway/web/irccloud.com/x-uofsmevexvbhbxdr] has quit [Read error: Connection reset by peer]
01:37 -!- fanquake [sid369002@gateway/web/irccloud.com/x-asrnjecwrkowwvfh] has joined ##taproot-activation
01:46 <@michaelfolkson> Rusty blog post: https://rusty.ozlabs.org/?p=628
02:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds]
02:23 <@michaelfolkson> AaronvanW article: https://bitcoinmagazine.com/articles/lottrue-or-lotfalse-this-is-the-last-hurdle-before-taproot-activation
02:26 <@michaelfolkson> Greg on Reddit: https://www.reddit.com/r/Bitcoin/comments/lrfm5b/lottrue_or_lotfalse_this_is_the_last_hurdle/gorasax/
02:26 <@michaelfolkson> Greg describes "existing software will be retrofitted by flipping a hidden config option"
02:27 <@michaelfolkson> Rusty describes "developers need to supply this option (setting it should also change the default User-Agent string, for signalling purposes)"
02:31 <@michaelfolkson> I include this from the recent Sydney Socratic (with Rusty's permission, the rest of the transcript is anonymized)
02:31 <@michaelfolkson> "I like a hidden option in Core which is always there from day one, which is lot=true or taproot-bip8-lot-true or something that would change lockinontimeout to true and also change the default user agent string so you can tell people are running it. That’s good because by the time 6 months comes almost everyone has upgraded anyway, they’ve just got to change their config."
02:41 <@michaelfolkson> To be clear a user agent string is a 'vanity-plate' for clients to distinguish themselves in the network
02:42 <@michaelfolkson> "User agents provide extra tracking information that is useful for keeping tabs on network data such as client implementations used or common architectures/operating-systems."
02:42 <@michaelfolkson> https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki
02:43 <@aj> gosh it's hard to read comments in reddit now
02:44 < DigDug> it sure is
02:44 < DigDug> have you heard of teddit.net?
02:46 <@michaelfolkson> DigDug: No, I have now
02:49 <@michaelfolkson> I don't even know how you change that user agent string normally. Presumably you already can through the config
02:55 < darosior> michaelfolkson: the `uacomment` config option
02:56 <@michaelfolkson> The P2P version message includes a variable string for user_agent
02:56 <@michaelfolkson> darosior: Thanks
02:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:00 <@michaelfolkson> So the Rusty suggestion is say a GUI switch for lot which when switched changes lot and at the same time automatically changes the user agent string
03:00 <@michaelfolkson> Probably not GUI, a config for lot that changes both lot and the user agent string at the same time
03:05 <@michaelfolkson> It is a pretty neat suggestion :)
03:06 < darosior> thinking about the "config option" solution brought up again by Rusty (it was dismissed early on because too dangerous iirc?). It's a bit concerning to have this "Bring Your Own Consensus Rules Yolo" way ... But on the other end people have been vocal about "The Community" :tm: without any actual way of polling it (or get arguments out of it). I
03:06 < darosior> also like how it takes F7 into account.
03:06 < darosior> The biggest concern is i think that people run random consensus rules in the future, but if they want footguns they can just delete their wallet.dat .. And the new rule would have to be implemented and released too. Maybe a compilation flag with some technical language to scare randos off ? Like ./configure --dangerous-force-activation <bit_number>
03:06 <@michaelfolkson> I still think there will be some opposed to it on the grounds that Core shouldn't implicitly encourage or make it easier for users to change lot to true
03:07 < darosior> I'm also not knowledgeable enough about what it takes on the implementation side of things to integrate a forced activation mechanism..
03:08 <@michaelfolkson> darosior: The forced option was dismissed early on. That was you are forced to choose lot before the software will run
03:09 <@michaelfolkson> That was not a good idea, from user experience or technical viability (imo)
03:10 <@michaelfolkson> Rusty's suggestion is there is a default set (lot=false) and then you make it easy to change to lot=true and you announce it in your P2P version message automatically
03:11 <@michaelfolkson> It is much better than the forced "you must choose before you can run the software" suggestion
03:12 <@michaelfolkson> That was trying to avoid setting a default (which I think is unavoidable)
03:12 < darosior> michaelfolkson: agreed, but some will disagree about that default... And circles again
03:12 < darosior> Making it a compilation flag also avoid people downloading binaries to set it, arguably further reducing the footgun surface
03:13 <@michaelfolkson> darosior: There are enough Core contributor NACKs that lot=true is not going to be set as the default
03:13 <@michaelfolkson> darosior: The getting back into circles danger is yes/no Core shouldn't make it easy to change that default
03:15 < darosior> There are multiple levels of 'easiness', also if the option is available it means the forced signaling was implemented: what does implementing a force signaling in bitcoind takes for 2021 Bitcoin ?
03:16 <@michaelfolkson> darosior: Or another circles danger is yes/no Core shouldn't release anything with a default
03:25 <@michaelfolkson> darosior: "what does implementing a force signaling in bitcoind takes for 2021 Bitcoin ?" I don't know what you mean by this. Technically?
03:44 < darosior> michaelfolkson: i mean technically, yes
03:44 < darosior> What has been discussed this week on the ML and here basically
03:51 <@michaelfolkson> I don't think there is anything to be done codewise in preparation for a very unlikely chain split. Communications could be important. And being able to see what other people are running on the network is handy
03:52 <@michaelfolkson> But I don't know how hard it is to implement the Rusty suggestion. It sounds doable to me
03:52 <@michaelfolkson> (for whatever that is worth lol)
04:00 <@michaelfolkson> Normally with an upgrade you'd disconnect from your peers, upgrade and then reconnect (and/or find new peers)
04:01 <@michaelfolkson> With this I think you'd do the same even though you aren't technically upgrading to a new version. You'd have to disconnect and then do the version, verack handshake again with a new version message (including the new user agent string)
04:34 -!- _0x0ff- [~potatoe@2001:bc8:47b0:123::1] has quit [Quit: into the offlines]
04:34 -!- _0x0ff [~potatoe@163.172.166.225] has joined ##taproot-activation
04:34 -!- _0x0ff [~potatoe@163.172.166.225] has quit [Changing host]
04:34 -!- _0x0ff [~potatoe@unaffiliated/0x0ff/x-1210984] has joined ##taproot-activation
06:08 -!- jonatack [~jon@37.173.36.152] has joined ##taproot-activation
06:13 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]
06:17 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
06:24 -!- brg444 [uid207215@gateway/web/irccloud.com/x-xngputqdkmzpojmw] has joined ##taproot-activation
06:25 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
06:25 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
06:25 -!- emzy [~quassel@2a01:4f8:192:628a::83] has quit [Changing host]
06:25 -!- emzy [~quassel@unaffiliated/emzy] has joined ##taproot-activation
06:48 -!- jonatack [~jon@37.173.36.152] has quit [Read error: Connection reset by peer]
06:48 -!- jonatack_ [~jon@37.173.36.152] has joined ##taproot-activation
06:55 -!- jonatack_ [~jon@37.173.36.152] has quit [Quit: jonatack_]
06:56 -!- jonatack [~jon@37.173.36.152] has joined ##taproot-activation
07:07 -!- jonatack_ [~jon@37.173.36.152] has joined ##taproot-activation
07:07 -!- jonatack [~jon@37.173.36.152] has quit [Read error: Connection reset by peer]
07:08 -!- jonatack_ [~jon@37.173.36.152] has quit [Client Quit]
07:09 -!- jonatack [~jon@37.173.36.152] has joined ##taproot-activation
07:12 -!- jonatack [~jon@37.173.36.152] has quit [Excess Flood]
07:14 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
07:19 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 276 seconds]
07:26 -!- jonatack [~jon@37.173.36.152] has joined ##taproot-activation
07:59 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Quit: Lost terminal]
08:01 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined ##taproot-activation
08:29 -!- belcher_ is now known as belcher
09:22 <@michaelfolkson> A repo is set up for a default lot=true release of Bitcoin Core (as they are free to do) https://github.com/BitcoinActivation
09:23 <@michaelfolkson> It is my (personal) expectation that Core will release default lot=false perhaps with a config option for users to change to lot=true
09:24 < luke-jr> hopefully not
09:35 -!- jonatack [~jon@37.173.36.152] has quit [Ping timeout: 265 seconds]
09:40 < luke-jr> https://github.com/bitcoin/bitcoin/pull/19573 looks ready to merge tho
09:40 -!- jonatack [~jon@37.173.36.152] has joined ##taproot-activation
10:33 < nickler> luke-jr: If it's not getting merged soon, are you considering removing lot from the PR?
10:34 < nickler> That may accelerate the process quite a bit because it seems that this will either be dead code for quite a while or never used in Core.
10:34 < luke-jr> nickler: definitely not
10:34 < luke-jr> nickler: it is ready to merge now. there is no reason it shouldn't be
10:35 < luke-jr> it has the required ACKs
10:37 < nickler> I can't judge if it has had enough reviews.
10:43 <@michaelfolkson> The ACKs are mostly from relatively inexperienced reviewers like myself
10:44 <@michaelfolkson> (Thus far)
10:55 < nickler> luke-jr: did you see this? (1h left) https://twitter.com/AaronvanW/status/1365032903986536452
11:04 < luke-jr> nickler: no
11:04 < luke-jr> polls worded like this assume voters already understand the implications of LOT correctly, but still a useful datapoint perhaps
11:08 < nickler> AaronvanW published an article about the implications before the poll
11:09 < nickler> more discussion here https://www.reddit.com/r/Bitcoin/comments/lrfm5b/lottrue_or_lotfalse_this_is_the_last_hurdle/ Very lot=False by default heavy at least in the most upvoted top-level comments.
11:09 < luke-jr> nickler: I didn't find it fully satisfying (thouhg it wasn't terrible)
11:20 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
12:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
12:02 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-activation
12:04 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
12:05 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
12:05 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
12:08 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
12:11 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
12:12 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
12:15 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
12:16 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
12:18 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Client Quit]
12:48 < brg444> I think it's useful to consider that some people are dead set on running =true, regardless of defaults and that number is likely to increase as time passes. It's probably in everyone's best interest to have a =true implementation at hand. At least I'm hoping this is enough to sidestep more contentious talk about making the Core release configurable.
12:49 < brg444> If certain Core developers can at least vouch for the sanity of this release then they can safely point interested parties that way rather than waste time re-iterating why they think a =true option isn't compatible with Core's ethos
12:50 < brg444> In the event that they don't change their mind about this then they can hopefully focus on an mvp version of lot=false and get this off the ground
12:51 < luke-jr> best if no LOT=False is ever released
12:53 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
13:08 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
13:11 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 276 seconds]
13:20 -!- belcher_ is now known as belcher
13:23 <@michaelfolkson> "sidestep more contentious talk about making the Core release configurable" Why is Core being configurable contentious brg444?
13:24 <@michaelfolkson> No one might open a Core PR to make it configurable, that is certainly a possibility.
13:24 -!- jonatack_ [~jon@37.167.224.27] has joined ##taproot-activation
13:25 -!- jonatack [~jon@37.173.36.152] has quit [Ping timeout: 265 seconds]
13:42 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Read error: Connection reset by peer]
13:43 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
13:53 <@michaelfolkson> I guess the only way to find out if it is contentious is to ask... I'll ask on #bitcoin-core-dev
14:13 <@michaelfolkson> Reading Greg's Reddit post again
14:13 <@michaelfolkson> "if taproot doesn't activate promptly.... updated software will be released with LOT=T and the same ending date and existing software will be retrofitted by flipping a hidden config option."
14:14 <@michaelfolkson> https://www.reddit.com/r/Bitcoin/comments/lrfm5b/lottrue_or_lotfalse_this_is_the_last_hurdle/gorasax/
14:15 <@michaelfolkson> I'm not sure what "retrofitting" means. Downloading a patch to flip a hidden config option that isn't easily accessible otherwise?
14:15 <@michaelfolkson> If that's the case might as well be a fresh release?
14:16 < belcher> i doubt it it means patching/recompiling, i read that as meaning it has a hidden config option already included which is just changed from false to true
14:17 <@michaelfolkson> But is it coded to change or does the user change it?
14:17 <@michaelfolkson> It is surely not the former...
14:18 < belcher> "config option" implies the user changes it
14:18 <@michaelfolkson> So why is it hidden? If the user is allowed to change it?
14:19 < belcher> id guess because making it hidden stops a casual user from doing it accidently just by playing around and thereby possibly losing money
14:19 < belcher> core already has `invalidateblock` which is hidden
14:20 <@michaelfolkson> And so instructions for accessing this hidden config would be widely distributed after a period of miners not activating?
14:20 < belcher> invalidateblock is very useful for simulating reorgs on regtest
14:20 < belcher> yeah i suppose, thats the impression i got from gmaxwell's post
14:21 <@michaelfolkson> Thanks for answering, I know I'm asking you to explain someone else's post :)
14:22 <@michaelfolkson> I guess I'm going to look up how invalidateblock is hidden :)
14:23 < belcher> oh hold on i just remembered, invalidateblock is an RPC call not a config option... though im pretty sure there are also hidden config options
14:33 < harding> I'm not aware of any truly hidden config options, but there's the regular options listed in -help and the not-for-regular-users options in -help-debug
15:05 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 256 seconds]
15:14 < jonatack_> michaelfolkson: git grep "Not shown in help"
15:15 < jonatack_> michaelfolkson: but that's for RPCs
15:16 <@michaelfolkson> jonatack_: Thanks
15:16 < jonatack_> for hidden config args, look in src/init.cpp
15:17 < jonatack_> git grep hidden_args
15:26 -!- jonatack_ [~jon@37.167.224.27] has quit [Ping timeout: 264 seconds]
15:27 < luke-jr> michaelfolkson: in the past 3-4 years, Core has made it harder to change consensus params at runtime; it's still possible and maybe not even that difficult, but the code to do so might be uglier and harder to get ACK'd
15:38 <@michaelfolkson> luke-jr: Ok thanks. So brg444 is likely right. If Core releases anything it seems it will be lot=false as a default with no user config option (hidden or otherwise)
15:40 <@michaelfolkson> Tbh that's where I thought we'd end up
16:03 -!- brg444 [uid207215@gateway/web/irccloud.com/x-xngputqdkmzpojmw] has quit [Quit: Connection closed for inactivity]
16:38 -!- jonatack_ [~jon@37.167.35.203] has joined ##taproot-activation
16:42 -!- jonatack_ [~jon@37.167.35.203] has quit [Read error: Connection reset by peer]
17:49 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
18:47 -!- brg444 [uid207215@gateway/web/irccloud.com/x-hpmuwukpfclzfzft] has joined ##taproot-activation
18:48 < brg444> because Core should not be liable for splitting consensus
18:52 < brg444> it's one thing for users to run whatever software they see fit. another for core to release potentially conflicting versions themselves
18:52 < brg444> pretty ill advised imo
18:56 < luke-jr> brg444: LOT=False makes Core responsible for splitting consensus
18:57 < luke-jr> well, to the same extent (which is IMO not much)
18:57 < nothingmuch> "at runtime" only implies a GUI option is tricky, right?
18:57 < luke-jr> no
18:57 < luke-jr> right now it's const at compile time
19:06 < nothingmuch> hmm, i'm really unfamiliar with these parts of the source, but what precludes modification of the chain parameters at first stages of AppInitMain, before the block index is loaded?
19:08 < nothingmuch> iow, is it just the constness or an architectural limitation?
19:09 < luke-jr> well, the code to change it exists for regtest
19:09 < luke-jr> it's just not designed to be changed
21:09 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
21:50 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection]
21:51 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
22:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
22:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##taproot-activation
22:33 -!- rotten [~rottensox@unaffiliated/rottensox] has joined ##taproot-activation
23:07 -!- alecfrancis [01886b03@1.136.107.3] has joined ##taproot-activation
23:13 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection]
23:14 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 276 seconds]
23:14 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
23:28 -!- alecfrancis [01886b03@1.136.107.3] has quit [Quit: Connection closed]
23:36 -!- brg444 [uid207215@gateway/web/irccloud.com/x-hpmuwukpfclzfzft] has quit [Quit: Connection closed for inactivity]
--- Log closed Sat Feb 27 00:00:41 2021