--- Log opened Wed Feb 03 00:00:34 2021
00:16 -!- liberliver [~Thunderbi@x4dbf3f91.dyn.telefonica.de] has joined ##taproot-activation
00:20 -!- iduno8912 [~Devan@cpe-172-113-125-218.socal.res.rr.com] has quit [Read error: Connection reset by peer]
00:20 -!- Whatisthis [54184fb9@84-24-79-185.cable.dynamic.v4.ziggo.nl] has joined ##taproot-activation
00:20 < Whatisthis> Hello
00:25 -!- fidiid [54184fb9@84-24-79-185.cable.dynamic.v4.ziggo.nl] has joined ##taproot-activation
00:25 -!- fidiid [54184fb9@84-24-79-185.cable.dynamic.v4.ziggo.nl] has quit [Client Quit]
00:25 -!- Whatisthis [54184fb9@84-24-79-185.cable.dynamic.v4.ziggo.nl] has quit [Quit: Connection closed]
00:26 -!- gnoek [~gnoek@ip2-4-176-143.adsl2.static.versatel.nl] has quit []
00:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
00:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds]
01:22 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
01:24 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
01:32 -!- pox [~pox@82.114.45.173] has quit [Ping timeout: 240 seconds]
01:56 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 258 seconds]
02:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:13 -!- QVO870 [d5d163f8@213.209.99.248] has joined ##taproot-activation
02:14 -!- QVO870 [d5d163f8@213.209.99.248] has quit [Client Quit]
02:50 -!- rich [~rich@shindig.notmandatory.org] has joined ##taproot-activation
02:53 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection]
03:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
03:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
03:05 < michaelfolkson> An additional view from kekcoin on Mastodon (didn't attend the meeting yesterday)
03:05 < michaelfolkson> It's a UASF not a DASF, so ship Bitcoin Core with LOT = configurable by command line parameter or config file, default false. Making it "configurable" by re-compiling doesn't work, as that is non-trivial even for technical users.
03:25 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
03:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
03:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
04:10 -!- belcher_ is now known as belcher
04:12 < virtu> #michaelfolkson: assuming people that have a strong opinion as to LOT have the technical background to re-compile, maybe it's a good thing to make deviating from the "community consesus" non-trivial
04:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:15 < virtu> also, it would be a good idea to have infrastructure in place to detect sybil attacks so an informed decision can be made by all participants as to the amount of support for UASF
04:16 < virtu> otherwise, saboteurs might just spin up several thousand amazon nodes with version strings indicating support for UASF
04:16 -!- ElAlquimista [3e532d36@62.83.45.54.dyn.user.ono.com] has joined ##taproot-activation
04:17 -!- ElAlquimista [3e532d36@62.83.45.54.dyn.user.ono.com] has quit [Client Quit]
04:24 < michaelfolkson> I don't think that infrastructure exists (to the extent that it is possible). Personally I would rather only discuss UASF to the extent that it impacts the decisions that need to be made for what should be the happy path towards Taproot activation
04:26 < michaelfolkson> Thanks to rusty for attempting the first summary of the meeting https://bitcoinhackers.org/@rusty/105664386728806153
04:32 < belcher> good summary
04:33 < belcher> someone there is talking about not being able to use freenode over tor, if needed there are other irc networks which support tor
04:33 < belcher> e.g. darkscience IRC and hackint IRC
04:57 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
05:05 < michaelfolkson> Ok thanks belcher. I will respond with this
05:23 -!- narcelio1 [~nf@179.186.160.103] has joined ##taproot-activation
05:34 < belcher> in the #joinmarket channel we have an IRC bot bouncer which relays messages between #joinmarket on freenode and #joinmarket on darkscience/hackint, so that allows people to use tor if they want without requiring other people to leave freenode
05:38 < michaelfolkson> Cool, didn't know about that channel
06:00 -!- CARO2 [~Cesar@2804:7f4:c298:45af:b5c8:1106:a25b:ed2c] has quit [Ping timeout: 272 seconds]
06:14 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
06:18 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
06:26 < setpill> On one hand only providing an official LOT-false build opens a vector for a malicious entity to provide backdoored LOT-true builds, on the other hand the LOT-true build niche will probably be filled by a trusted community member.
06:35 < belcher> the threat of backdoored builds can be easily resisted if it comes to that, the community did it during bip148
06:35 < virtu> belcher: weird. freenode over tor works for me
06:36 < belcher> virtu interesting, i know their policies change all the time, fwiw the #joinmarket bots were started years ago
06:39 < setpill> https://freenode.net/kb/answer/chat#accessing-freenode-via-tor
06:47 < belcher> it seems like to set up a SASL account you need to connect at least once via clearnet, which is what that toot was about
06:51 < michaelfolkson> Follow up to the Bitcoin dev mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018379.html
06:55 < devrandom> there's no consensus on the threshold (90%, 95%) yet, right?
06:58 -!- blk014 [9270e3d5@146.112.227.213] has joined ##taproot-activation
06:59 < blk014> Is there a summary of conclusions available somewhere about the recent taproot activation meeting here?
06:59 -!- liberliver1 [~Thunderbi@dynamic-089-012-226-086.89.12.pool.telefonica.de] has joined ##taproot-activation
07:00 < belcher> blk014 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018379.html
07:00 < michaelfolkson> devrandom: No my guess from aj developer survey it will be 90 percent or 95 percent as you say
07:01 < blk014> Great, thanks!
07:01 -!- liberliver [~Thunderbi@x4dbf3f91.dyn.telefonica.de] has quit [Ping timeout: 258 seconds]
07:01 -!- liberliver1 is now known as liberliver
07:02 < michaelfolkson> devrandom: I think that leans towards 90 percent though aj recommendation was 95 percent
07:06 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
07:07 -!- blk014 [9270e3d5@146.112.227.213] has quit [Quit: Connection closed]
07:11 < michaelfolkson> http://www.erisian.com.au/wordpress/2020/10/26/activating-soft-forks-in-bitcoin
07:29 -!- benthecarman [~benthecar@h133.169.131.40.static.ip.windstream.net] has joined ##taproot-activation
07:36 < luke-jr> Reminder that a UASF only enforced by part of the community is much more dangerous and requires extra code to ensure clean peering and overwrite
07:40 < michaelfolkson> What's that reminder in reference to luke-jr?
07:42 < luke-jr> talk about having LOT=false and LOT=true run by different releases/people
07:42 < luke-jr> it's better than all LOT=false, but still not a safe solution
07:45 < michaelfolkson> So would the better strategy be if LOT=false is set as default that even people like you who would prefer LOT=true still run LOT=false?
07:45 < michaelfolkson> It seems like we should all be running LOT=true or LOT=false right?
07:45 < luke-jr> no, that's the one I'm criticising
07:46 < luke-jr> all LOT=true is far better than partial LOT=true
07:46 < luke-jr> partial LOT=true is better than all LOT=false
07:46 < michaelfolkson> And all LOT=false is far better than partial LOT=true?
07:46 < luke-jr> no
07:46 < luke-jr> [15:46:19] <luke-jr> partial LOT=true is better than all LOT=false
07:47 < luke-jr> only all LOT=true ensures a safe deployment
07:47 < michaelfolkson> Oh sorry ok
07:47 < luke-jr> partial or LOT=false enables sabotage
07:51 < michaelfolkson> The argument that all LOT=false enables sabotage is that the act of anybody at all going with LOT=true causes some chaos?
07:51 < michaelfolkson> In a hypothetical world where literally not single node goes LOT=true, all nodes are LOT=false I don't see the problem
07:54 < michaelfolkson> Of course you can't guarantee this hypothetical world. It is hypothetical
07:56 -!- benthecarman [~benthecar@h133.169.131.40.static.ip.windstream.net] has quit [Ping timeout: 240 seconds]
08:00 < luke-jr> the problem is Taproot doesn't activate, and miners are incentivised to hold it hostage
08:00 < luke-jr> LOT=true strictly reduces the risk
08:03 < michaelfolkson> Ok yeah. A year delay is a possibility
08:05 < michaelfolkson> Mining pool data suggests it is unlikely https://taprootactivation.com/
08:06 < michaelfolkson> I guess it depends on whether there is anything to gain from holding it hostage for a year or not. I can't see anything but maybe I'm not imaginative enough
08:06 < luke-jr> if not, then LOT doesn't matter
08:07 < luke-jr> when determining LOT, it only makes sense to assume miners will not
08:07 < michaelfolkson> Yeah I think your argument is convincing. Why take that chance of the hostage outcome however small...
08:09 < michaelfolkson> The opposing argument to this is that you want a clean exit path in the unlikely scenario that there is a bug found in the code
08:09 < michaelfolkson> So weighing up risk of hostage outcome versus a problem found in Taproot code
08:10 < michaelfolkson> No matter how much review is done we cannot guarantee there won't be bugs
08:11 < michaelfolkson> I think that's why I preferred LOT=false
08:11 < michaelfolkson> Worst case is a year is wasted
08:12 < michaelfolkson> Worst case with LOT=true is there is a problem found in Taproot code and we need to scramble an exit path
08:13 < luke-jr> if a bug is found in the code, people who have upgraded will need to act period
08:13 < luke-jr> also consider the risk that miners like the bug and activate to exploit it
08:14 < luke-jr> if the risk of a bug is greater than the incentive of miner sabotage created, we shouldn't be activating at all yet
08:15 < luke-jr> both alternatives have problems if there are bugs; but LOT=false creates problems even if the code is fine
08:19 < michaelfolkson> Yeah I think you are convincing. I'm not perfectly clear on how exit paths compare if a bug is found with LOT=true versus with LOT=false. With LOT=false, the bug could be identified and miners could simply not activate. With LOT=true, everyone would need to emergency upgrade right?
08:20 < michaelfolkson> LOT=false sounds better to me. If I've outlined scenarios correctly
08:22 < michaelfolkson> I don't like hostage scenario though if you only need 5 percent (or best 10 percent) of hash rate to keep everyone waiting a year
08:22 < luke-jr> with LOT=false everyone needs to upgrade anyway
08:23 < luke-jr> even if the bug miraculously doesn't affect anything without activation, and miners don't activate anyway, you still need a new version with new activation bugfix-included
08:24 < michaelfolkson> > with LOT=false everyone needs to upgrade anyway
08:24 < michaelfolkson> Not if threshold hasn't been reached
08:24 < michaelfolkson> It would never get activated
08:24 < luke-jr> see next msg
08:25 < luke-jr> and the chance a bug fits those perfect contraints in the first place, is even smaller than any bug at all being found (which is itself very unlikely)
08:25 < michaelfolkson> > you still need a new version with new activation bugfix-included
08:25 < michaelfolkson> Ok yeah. But that new version isn't an emergency upgrade
08:26 < michaelfolkson> That new version could be done after the year
08:26 < luke-jr> so it amounts to a niche case of a niche risk, where you could avoid upgrading if you take the risk of trusting miners simply to delay an inevitable upgrade
08:27 < luke-jr> vs creating a substantial, real-world risk that compromises the incentives of the system
08:27 < luke-jr> (and has in practice been exploited before, nearly taking Bitcoin down with it)
08:28  * luke-jr wonders if we've ever had to cancel a softfork due to a bug before.
08:30 < michaelfolkson> I think your argument is convincing. In my "niche scenario" it would just be nodes running 21.x who would need to emergency upgrade
08:31 < michaelfolkson> And it really shouldn't happen. It would be an emergency and deserves an emergency response
08:32 < belcher> i still dont see why lot=false gives miners an incentive to hold taproot hostage, again miners get paid in bitcoin and want its utility to go up, they have a strong incentive to activate it (which explains the 90% support we've seen)
08:33 < michaelfolkson> It is not an incentive, it just opens that possibility up as a possibility
08:33 < belcher> luke-jr is saying its an incentive, and that justifies lot=true
08:33 < luke-jr> belcher: those are counter-acting incentives, but they're weighed against the incentive to make demands in exchange for something of value (activation)
08:34 < luke-jr> the incentive doesn't disappear just because other incentives exist
08:34 < luke-jr> miners had an even stronger incentive to active Segwit
08:34 < belcher> not correct, lots of miners were hurt by covert asicboost being stopped
08:34 < belcher> the miners are in no position to demand anything, they've seen what happened in 2017
08:36 < luke-jr> IIRC someone wrote a long article about this
08:36 -!- benthecarman [~benthecar@h133.169.131.40.static.ip.windstream.net] has joined ##taproot-activation
08:36 < luke-jr> I forget who
08:36 < belcher> yesterday i realized that the page taprootactivation.com was actually made by someone who runs a mining pool, so it represents the miners taking the initiative to organize themselves to figure out if they'll signal for taproot... thanks to that we have that information now and its ~90% approval
08:37 < luke-jr> belcher: again, to discuss LOT requires assuming miners don't activate
08:37 < belcher> i dont see why, why would we ignore the information we have about 90% approval
08:38 < michaelfolkson> Because it is pledged not guaranteed
08:38 < michaelfolkson> It isn't locked in
08:38 < belcher> if we assume miners wont activate why bother with miner signalling at all? just make it a bip149-style UASF with no miner signalling
08:38 < belcher> assuming miners dont activate seems a very bad assumption, we have loads of information to the contrary
08:39 < michaelfolkson> It is scenario planning. I'm not assuming anything. You have to assign probabilities to different scenarios
08:39 < luke-jr> belcher: with miner activation, LOT is literally irrelevant
08:39 < luke-jr> we only assume they won't for the purpose of LOT discussion
08:39 < luke-jr> and BIP149 is bad even if miners wouldn't cooperate at all
08:40 < luke-jr> there's very few situations where BIP149 is a sane approach
08:40 < belcher> bip8 with lot=true but miners not signalling seems to be exactly the same as bip149 (admittedly it has been a few years since i read bip149)
08:41 < michaelfolkson> I guess if miners didn't activate after pledging over 90 percent for Taproot, that would be an argument for not doing lot=false ever again
08:41 < belcher> for example you still get the uncertainty of not knowing if enough of the economy runs the soft fork nodes, which mean lead to users being too scared to actually use taproot outputs in case the miners steal them
08:41 < belcher> michaelfolkson agreed
08:42 < belcher> i should point out that back in segwit times we had noises from places like r/btc that miners will block segwit activation, before segwit itself was even coded
08:42 < belcher> pieter wuille gave the famous segwit talk at a conference and on the same day big blockers were saying it sucks and theres no way it will get into bitcoin
08:42 < belcher> the situation today is totally different
08:43 < michaelfolkson> Agreed, I think we all agree the probability of it happening this time is vastly diminished. But not zero
08:44 < belcher> lot=true has risks as well, so we have to trade off those with the risks of miners holding taproot hostage
08:44 < belcher> i think thats why so many people talked about lot=false first and if the miners end up holding it hostage then going to some kind of lot=true situation
08:44 < luke-jr> michaelfolkson: miners pledged over 90 percent for Segwit too..
08:45 < belcher> that cant be true
08:45 < michaelfolkson> You including pledging for SegWit2x in that?
08:45 < luke-jr> no
08:45 < belcher> bitmain for example said in 2016 they will never activate segwit unless bitcoin core does a hard fork
08:46 < belcher> evidence: https://bitcoinmagazine.com/articles/antpool-will-not-run-segwit-without-block-size-increase-hard-fork-1464028753/ dated may 2016
08:46 < luke-jr> https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff
08:46 < belcher> "When asked specifically whether Antpool would run SegWit code without a hard fork increase in the block size also included in a release of Bitcoin Core, Wu responded: “No. It is acceptable that the hard fork code is not activated, but it needs to be included in a ‘release’ of Bitcoin Core. I have made it clear about the definition of ‘release,’ which is not ‘public.’”"
08:47 < belcher> luke-jr that post talks about there being a hard fork to 2mb non-witness data
08:47 < belcher> so the same thing that my quote says, obviously a hard fork was unacceptable
08:47 < belcher> right now those 90% of miners are not asking for any kind of hard fork in return for taproot
08:48 < luke-jr> great, so LOT won't matter and should be true on principle
08:48 < luke-jr> either way it should be true
08:49 < belcher> i say "miners will surely signal for taproot so lot should be false, you say "miners will surely signal for taproot so lot should be true"
08:49 < belcher> is that a fair way of describing the point we got to?
08:50 < michaelfolkson> Tbh I'd be happy with either lot=true or lot=false. Whichever side feels most strongly. My assessment at the moment is majority is lot=false but we might be in another intolerant minority scenario where majority doesn't care that much
08:52 < michaelfolkson> I don't want a war over lot=true vs lot=false lol
08:52 < belcher> everyone can always run whatever code they like
08:52 < luke-jr> belcher: you're the one who insists on looking at LOT only in the situation it doesn't matter ;)
08:52 < belcher> there's likely to be contention about what code is in bitcoin core
08:53 < luke-jr> belcher: if miners will surely signal for taproot, why give them a nuclear option?
08:54 < michaelfolkson> Ok I'm exiting. I don't think a year wasted is a nuclear option though. We shouldn't exaggerate magnitude of worst case scenario
08:54 < belcher> luke-jr because lot=true adds more of a risk, however small, to me it doesnt seem worth it
08:54 < belcher> to put another way, i think the risk of miners holding it hostage is smaller than the risk of lot=true
08:55 < belcher> remember with lot=true but no miners signalling, its still unclear how much of the economy actually enforces the new rules, which might make people scared to put coins into taproot outputs
08:55 < luke-jr> no, LOT=true removes risk only
08:55 < luke-jr> LOT=true requires miners to signal
08:56 < belcher> rusty wrote an argument that "Having bitcoin ship with lockin=true feeds perception that devs de-facto control the protocol (defaults are *sticky*!).  I consider that more dangerous, long term, than Taproot not activating easily.", what are your thoughts on that?
08:57 < belcher> i dont develop much on bitcoin core but i can understand why they dont want that perception, especially since we already saw things like craig wright causing grief against bitcoincore.org
08:57 < luke-jr> it's based on the fasle premise that activation is decision-making
08:58 < belcher> signalling is decision-making, if signalling is 95% over 2016 blocks (or whatever the parameters are) then taproot gets activated by that method
08:58 < luke-jr> also, Bitcoin doesn't ship. Core is not Bitcoin.
08:58 < luke-jr> belcher: no
08:58 < luke-jr> signalling is coordination
08:59 < luke-jr> the decision must be made before any activation is deployed at all
08:59 < belcher> decision to activate must include a decision for which block height to start enforcing the new rules
09:00 < belcher> thats what signalling does, it gives every node information about which block height to start enforcing
09:00 < belcher> so its part of the decision
09:00 < belcher> we use miner signalling because its easy to measure without centralization
09:01 < luke-jr> if there is community support to deploy Taproot, activation is a given; deploying that is not forcing a protocol change, it is complying
09:01 < luke-jr> we use miner signalling because it's faster than waiting a year
09:01 < belcher> what does the community say about which block height should be the one where the new rule starts being enforced?
09:01 < luke-jr> that's what we're here to determine
09:09 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Remote host closed the connection]
09:10 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
09:28 -!- narcelio1 [~nf@179.186.160.103] has quit [Ping timeout: 246 seconds]
09:36 -!- benthecarman [~benthecar@h133.169.131.40.static.ip.windstream.net] has quit [Ping timeout: 258 seconds]
09:45 -!- mango [~mango@c-73-71-224-94.hsd1.ca.comcast.net] has joined ##taproot-activation
10:15 < devrandom> michaelfolkson: intuitively 90% seems enough and is less affected by laziness or attempts by small players to pressure. but I wonder if anybody has any technical/safety reasons to differentiate between 90% and 95%
10:16 < michaelfolkson> It is a typical trade-off right. Too low and it might activate with significant opposition. Too high and it might never activate
10:17 < michaelfolkson> It depends what you are more worried about
10:17 < michaelfolkson> I should clarify miner opposition when I say opposition
10:17 -!- jonasschnelli [~jonasschn@2a01:4f9:2a:2510::2] has quit [Changing host]
10:17 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined ##taproot-activation
10:19 < michaelfolkson> I don't think there is any science behind picking the sweet spot of that trade-off other than asking people (ideally people who have thought this through a lot and been involved in prior activations) where they think the sweet spot it
10:19 < michaelfolkson> *is
10:19 < michaelfolkson> *sweet spot is.
10:19 < michaelfolkson> My damn typing
10:26 < devrandom> I'm curious at what threshold it becomes a technical problem (i.e. not enough nodes have upgraded and the result is unstable), rather than a political question
10:28 < devrandom> I think it's OK if there is some opposition, segwit had more than 10% opposition
10:30 < michaelfolkson> Ok so you are talking about user activated soft forks
10:30 < devrandom> no, still talking about MASF
10:31 < devrandom> I'm just saying that 9% opposition is politically acceptable, but I wonder if there are technical reasons why that level of opposition might cause instability
10:31 < michaelfolkson> Well the  percentage for a MASF is miners/blocks not nodes
10:31 < devrandom> 9% mining power
10:33 < michaelfolkson> But at least in theory 9 percent of the miners if they felt that strongly could hard fork the chain and have 9 percent of hash rate on it
10:33 < michaelfolkson> So it is situation dependent. The chances of the 9 percent doing that for Taproot seem to me extremely, extremely low
10:34 < michaelfolkson> But if we were back in 2017 we wouldn't know
10:36 < michaelfolkson> Are 9 percent refusing to activate out of apathy or out of direct and fulsome opposition to the soft fork change?
10:41 < michaelfolkson> An altcoin with 9 percent hash rate shouldn't be too bad. But if that 9 becomes 19, 29 it starts to get concerning
10:43 < michaelfolkson> Obviously if that 9 percent is fighting the consensus of the whole ecosystem they are going to lose money very quickly and they'll either go bankrupt or switch back to mining Bitcoin
10:46 < luke-jr> [18:16:47] <michaelfolkson> It is a typical trade-off right. Too low and it might activate with significant opposition. Too high and it might never activate
10:47 < luke-jr> that implies the signalling is a vote again
10:47 < luke-jr> it isn't
10:47 < luke-jr> it should either activate or not regardless of what miners think
10:48 < michaelfolkson> Well then why not have 1 percent or 10 percent threshold?
10:48 < luke-jr> if we still have doubt on whether Taproot has community support, we are not ready to begin activation
10:48 < michaelfolkson> Why bother with as high as 90?
10:49 < luke-jr> shrug
10:49 < luke-jr> part of it is voltaility of blocks
10:49 < luke-jr> we're probably fine anywhere over 85% I guess
10:51 < michaelfolkson> I do think signaling is more skin in the game than "pledging" in advance
10:51 < luke-jr> "pledging" makes no sense
10:51 -!- mango [~mango@c-73-71-224-94.hsd1.ca.comcast.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
10:51 < luke-jr> if we're giving them the power to coordinate it, it's also their duty to coordinate it
10:52 < luke-jr> it's not a choice for them to make
10:52 < michaelfolkson> We disagree on this Luke :)
10:52 < luke-jr> …
10:52 < michaelfolkson> I say miners are one of many constituents. You say they do not matter
10:53 < luke-jr> then we should just drop the MASF entirely and go pure UASF to send the point home ;)
10:54 < michaelfolkson> There is a spectrum between miners being all powerful and entirely powerless. You think they are entirely powerless. I just don't think that's right
10:54 < michaelfolkson> They definitely aren't all powerful, that's for sure
10:54 < luke-jr> there is a distinction between power and right
10:55 < luke-jr> in any case, the purpose of activation is to activate; not to vote or decide
10:55 < luke-jr> the decision occurs prior to activation being deployed at all
10:56 < luke-jr> to the extent that miners matter (if at all), that is something to resolve before we get to this point
10:56 < luke-jr> it is not something where miners just get to block activation by abusing the coordination
10:57 < michaelfolkson> So it is signaling readiness more than signaling support. If they don't signal it could mean they are apathetic, they aren't ready, they are secretly in opposition, or they are malicious
10:57 < michaelfolkson> All we see is whether they signal or not. We don't know why
10:57 < devrandom> they could also be pushing for some political concession
10:58 < michaelfolkson> Right and that's what was happening in 2017
10:58 < michaelfolkson> Either in the "secretly in opposition" or "malicious" category
10:59 < devrandom> pushing for a political concession during the activation period would just be bad faith, since they could have brought up whatever issue earlier
10:59 < luke-jr> point is that wilfully not signalling is wrong of them, not something we're asking them not to do
11:01 < devrandom> it seems to me that lowering the activation threshold (let's say to 90%) heads off both apathy and late-stage brinkmanship
11:02 < devrandom> an arguably also having a lot=true command line flag that can be turned on in reaction to brinkmanship
11:03 < michaelfolkson> That is available to users even if Core default is lot=false. But it is individual choice and hard to coordinate
11:04 < michaelfolkson> I don't think Core would set a default of lot=false in a release and then set a default of lot=true in a future release right luke-jr?
11:05 < luke-jr> michaelfolkson: Core has a history of failing to set LOT=true (BIP148) even when the community supports it
11:06 < luke-jr> hopefully that can change
11:06 < luke-jr> but I cannot predict the future :P\
11:07 < michaelfolkson> I suspect that might change if we end up waiting another year for Taproot :)
11:07 < luke-jr> BTW with LOT=false, 1y is too soon IMO
11:07 < luke-jr> we'd be back in the same scenario as BIP148 that way - rushed into a 6 month LOT=true
11:08 < luke-jr> which was widely recognised as recklessly rushed
11:08 < aj> bip148 was ~3 months
11:08 < aj> 6 months would've been awesome
11:09 < luke-jr> March to August is 5 months
11:10 < luke-jr> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html
11:11 < aj> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014234.html but that was prior to the date getting moved back to august
11:12 < aj> bah, wrong mail
11:12 < luke-jr> regardless, 6 months still seems quite rushed IMO
11:12 < luke-jr> for UASF
11:13 -!- benthecarman [~benthecar@h133.169.131.40.static.ip.windstream.net] has joined ##taproot-activation
11:14 < aj> https://github.com/bitcoin/bips/pull/512 is near enough, so all of april-july 4 months
11:14 < aj> yeah, i note rusty was saying at T=0 he'd do (false, T+12 months) then at T+6 months he'd do (true, T+9 months) which also seems very rushed, but similar to 148
11:15 < luke-jr> that doesn't work..
11:15 < luke-jr> 6+9 > 12
11:15 < luke-jr> nm
11:15 < luke-jr> so 6 months LOT=false, 3 months LOT=true
11:16 < luke-jr> that seems like crisis management timeframe
11:16 < aj> https://bitcoinhackers.org/@rusty/105664449877727721
11:21 < michaelfolkson> Yeah I like his reasoning
11:22 < michaelfolkson> We could all get behind that right?
11:23 < michaelfolkson> Relies on user coordination at the 6 month mark
11:23 < michaelfolkson> But avoids Core having to commit to a lot=true
11:25 < luke-jr> it's flawed reasoning, and creates a crisis situation
11:26 < luke-jr> seems likely it could be the route that has the *most* risk
11:27 < michaelfolkson> Ok if you feel this strongly Luke I'm happy to go with lot=true. But I don't know how we get majority consensus on it.
11:28 < michaelfolkson> Another meeting checking people are happy to go with lot=true? Doesn't sound great fun
11:29 < michaelfolkson> Or aj can dust down his survey tools
11:29 < luke-jr> I mean, that one is the worst of all the possible LOT=false scenarios probabyl :P
11:30 < luke-jr> maybe if there's no clear consensus post-code review, we can discuss it further at the next meeting
11:30 < luke-jr> definitely don't want it to become a heated thing tho
11:30 < luke-jr> just polite debate and hopefully we can find some consensus
11:31 < michaelfolkson> Ok maybe we try a follow up meeting then just on this topic and to finalize the "decision"
11:31 < luke-jr> well, we also need to sort out beginning height/time
11:31 < michaelfolkson> Something separate to the Core PR review club that we will hopefully do on your Core PR at some stage
11:32 < luke-jr> hopefully 0.20.2 will be out soon so "updated" on my graph is more useful XD
11:32 < luke-jr> or maybe I just make a new graph just for this
11:33 < michaelfolkson> Right beginning height too if we weren't willing to take precedent from SegWit on that
11:33 < michaelfolkson> Ok a finalization meeting. I'm happy to do it if it helps
11:36 < luke-jr> finalization won't be until after ML proposal
12:06 -!- benthecarman [~benthecar@h133.169.131.40.static.ip.windstream.net] has quit [Quit: benthecarman]
12:06 -!- benthecarman [~benthecar@h133.169.131.40.static.ip.windstream.net] has joined ##taproot-activation
12:13 < michaelfolkson> So a pre ML proposal meeting
12:13 < michaelfolkson> Finalizing the ML proposal
12:13 < michaelfolkson> Lol
12:19 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
12:23 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
12:32 < virtu> looking at past data 1-2mo worth of blocks seems fine for start time
12:34 < virtu> seems like 0.21 has mostly converged at around 15% after 19 days
13:24 -!- liberliver [~Thunderbi@dynamic-089-012-226-086.89.12.pool.telefonica.de] has quit [Quit: liberliver]
13:24 -!- liberliver1 [~Thunderbi@dynamic-089-012-226-086.89.12.pool.telefonica.de] has joined ##taproot-activation
13:29 -!- liberliver1 [~Thunderbi@dynamic-089-012-226-086.89.12.pool.telefonica.de] has quit [Ping timeout: 276 seconds]
14:16 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Quit: Lost terminal]
15:21 -!- benthecarman [~benthecar@h133.169.131.40.static.ip.windstream.net] has quit [Ping timeout: 240 seconds]
15:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds]
15:41 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
16:31 -!- queip [~queip@unaffiliated/rezurus] has joined ##taproot-activation
16:34 -!- benthecarman [~benthecar@h133.169.131.40.static.ip.windstream.net] has joined ##taproot-activation
16:38 -!- benthecarman [~benthecar@h133.169.131.40.static.ip.windstream.net] has quit [Ping timeout: 240 seconds]
16:52 -!- benthecarman [~benthecar@h133.169.131.40.static.ip.windstream.net] has joined ##taproot-activation
17:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
17:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left ##taproot-activation []
17:58 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
18:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
18:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
18:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
18:36 -!- benthecarman [~benthecar@h133.169.131.40.static.ip.windstream.net] has quit [Ping timeout: 258 seconds]
18:42 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
18:44 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
19:01 < aj> dr_orlovsky: presumably you'll get a github notification, but in case you don't https://github.com/bitcoin/bips/pull/1063
19:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
19:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
19:48 < dr_orlovsky> aj: thank you! will review in the morning
20:07 -!- rotten [~rottensox@unaffiliated/rottensox] has quit [Remote host closed the connection]
20:08 -!- rotten [~rottensox@unaffiliated/rottensox] has joined ##taproot-activation
20:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds]
22:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
22:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
23:28 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
23:28 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
--- Log closed Thu Feb 04 00:00:35 2021