--- Log opened Mon May 17 00:00:57 2021 00:59 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined ##taproot-activation 01:01 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation 01:03 -!- p0x [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 240 seconds] 02:34 -!- _joerodgers [~joerodger@c-71-238-223-242.hsd1.ar.comcast.net] has joined ##taproot-activation 02:36 -!- joerodgers [~joerodger@c-71-238-223-242.hsd1.ar.comcast.net] has quit [Ping timeout: 265 seconds] 03:24 < pox> btc.top signaling partially. things looking good. 03:58 -!- queip [~queip@unaffiliated/rezurus] has quit [Read error: Connection reset by peer] 04:11 -!- queip [~queip@unaffiliated/rezurus] has joined ##taproot-activation 04:12 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Remote host closed the connection] 04:15 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined ##taproot-activation 05:16 -!- _0x0ff- [~potatoe@2001:bc8:47b0:123::1] has quit [Quit: into the offlines] 05:17 -!- _0x0ff [~potatoe@163.172.166.225] has joined ##taproot-activation 05:17 -!- _0x0ff [~potatoe@163.172.166.225] has quit [Changing host] 05:17 -!- _0x0ff [~potatoe@unaffiliated/0x0ff/x-1210984] has joined ##taproot-activation 05:51 -!- roconnor [~roconnor@host-23-91-186-24.dyn.295.ca] has joined ##taproot-activation 05:51 -!- roconnor [~roconnor@host-23-91-186-24.dyn.295.ca] has left ##taproot-activation [] 06:07 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Quit: WeeChat 3.0] 06:57 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds] 08:01 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer] 08:03 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##taproot-activation 08:19 -!- proofofkeags [~proofofke@97-118-239-55.hlrn.qwest.net] has quit [Ping timeout: 260 seconds] 08:40 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##taproot-activation 09:00 < achow101> btc.top, 1thash.top, sigmapool, and 2 of huobi's servers are flip flopping in their stratum output 09:11 < CubicEarth> achow101: all of their servers are? 09:11 < achow101> all of btc.top and 1thash.top servers are (there's only 2 of each that I have) 09:12 < achow101> 2 of sigmapool's are flip flopping 09:12 < CubicEarth> do you have a theory? 09:13 < achow101> nope 09:13 < achow101> other than shit software and misconfiguration 09:17 < CubicEarth> I c 09:17 < achow101> it's also interesting that binance is issuing work that signals, but all their recent blocks are not signaling 09:17 < CubicEarth> hopefully they'll get it fixed before the next signaling period starts 09:17 < CubicEarth> chance, I guess 09:19 < robert_spigler> hm weird 09:21 < achow101> I think some of these might be the "smart pool" thing 09:22 < achow101> I'm not monitoring any of those stratum servers since they can issue work for sha256d altcoins 09:23 -!- duringo [2578d7e4@37.120.215.228] has quit [Ping timeout: 240 seconds] 09:49 -!- valwal1 is now known as valwal 10:29 < luke-jr> achow101: could the flip flopping be empty blocks? 10:31 < achow101> luke-jr: I don't think so. latest work I got from btc.top has merkle branches 10:35 < copumpkin> achow101: it's the opposite of shit software IMO 10:35 < copumpkin> staged rollouts are recommended good operational practice. If you have multiple servers (which many of these pools do) you don't want to do a big bang rollout of new code and risk taking down your entire pool if something goes wrong, so you upgrade a subset of servers (often just one) and see how it goes for a while, then if it looks good, do more 10:38 < achow101> unless they're switching out servers while I still have an open tcp connection with them, that's not likely 10:39 < copumpkin> load balancers are pretty common 10:39 < achow101> typically load balanecs only deal with setting up the connection 10:40 < copumpkin> not really 10:40 < copumpkin> anyway, just saying, are you thinking there's a single box behind these major pools 10:40 < copumpkin> or that they big bang upgrade 100 boxes at a time? 10:40 < copumpkin> I don't think the latter is great operational behavior 10:40 < achow101> for some pools, I expect that there is a single box behind each stratum url 10:40 < achow101> because a lot of pools have several stratum urls 10:42 < copumpkin> that's quite possible, hard to say, but there are SDN constructs that let you inject load balancers at all sorts of levels and at all of those levels there could be multiple boxes. And even if a pool has a bunch of stratum URLs and each is backed by a single box, if each of those boxes gets upgraded separately, you'd still see flip flopping, right? 10:43 < achow101> if each stratum url is backed by a single box, there shouldn't be flip flopping for any work issued by that server 10:43 < achow101> you might see it across the entire pool's blocks, and we do observe that 10:43 < copumpkin> yes 10:43 < achow101> but that would also manifest as some stratum urls issuing non-signaling work, and some do 10:43 < achow101> and I do observe that too 10:43 < achow101> e.g. btc.com has one stratum urls issuing signaling work, and the other 4 not 10:45 < copumpkin> yeah, so I'm still not seeing where the shit software or misconfiguration is coming in 10:46 < copumpkin> it could be, I just don't see the flip flopping as clear evidence of it yet :P 10:49 < achow101> it could be shit software as in the software is failing to persist a configured version number. or maybe it is hitting some kind of error that is causes it to set the version number to a default value which is non-signaling 10:49 < achow101> but I found the real answer anyways. this server is switching between coins, and occasionally I'm getting non-bitcoin work 10:49 < copumpkin> interesting 10:49 < copumpkin> that's btc.com? 10:50 < achow101> btc.top 10:50 < copumpkin> oh 10:50 < achow101> it just issued me work for a previous block hash of 0000000000000000004d93a0691fbb097eb92b9545a722f88499923f1fd7c140 which seems to be bch's tip 10:51 < copumpkin> fun 10:51 < achow101> I need to implement handling of this in my script.. 10:52 < copumpkin> what does your script do? 10:53 < achow101> Connects to a bunch of stratum servers and checks to see if the work they are issuing have a version number that signals for taproot 10:54 < copumpkin> ah nice 10:56 < copumpkin> seems pretty likely we'll be firmly in 90% territory next period 10:57 < copumpkin> unless I just jinxed it by saying that 10:57 < copumpkin> sorry folks 11:08 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection] 11:08 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation 11:37 -!- jesseposner [~jesseposn@2601:645:200:162f:89cf:52a8:5384:9f88] has joined ##taproot-activation 12:55 < CubicEarth> It's nice that we might be able to get 90% in the next period. But if we do this again... why shouldn't the threshold be 80%? 13:00 <@michaelfolkson> https://bitcoin.stackexchange.com/questions/102684/what-is-the-point-of-miner-signaling-in-a-soft-fork-activation-mechanism-what-s 13:01 <@michaelfolkson> https://bitcoin.stackexchange.com/questions/52326/what-are-the-risks-of-a-lower-than-95-activation-threshold-for-soft-forks-part 13:57 < achow101> Does anyone know if binance has their own hashpower? 14:02 < CubicEarth> michaelfolkson: Thanks. 14:03 < CubicEarth> But if we do a UASF because we failed to reach 90% ... then it seems we are accepting more risk than we attempted to avoid 14:07 <@michaelfolkson> The only risk with a UASF is if miners are unwilling or unable to enforce the soft fork rules at the time of the forced signaling. The forced signaling makes sure 90 percent are signaling 14:07 <@michaelfolkson> You have to put the threshold somewhere. Otherwise don't do any miner signaling 14:09 <@michaelfolkson> The risk isn't presented by the UASF or the forced signaling. The risk is presented by miners not signaling and uncertainty over whether they will enforce the soft fork rules when we want them to 14:09 <@michaelfolkson> The UASF, forced signaling are tools to address that risk if we need them 14:11 <@michaelfolkson> You don't need the forced signaling in a smooth sailing scenario. Hence in a no risk scenario there is no risk of forced signaling being applied 14:48 < luke-jr> CubicEarth: that implies UASFs are risky, which isn't really accurate 15:48 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has quit [Remote host closed the connection] 15:50 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined ##taproot-activation 16:02 -!- p0x [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation 16:05 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 240 seconds] 16:09 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation 16:13 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds] 16:14 -!- belcher_ is now known as belcher 17:07 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 252 seconds] 17:12 < roasbeef> it's tappening!!! 17:15 < Emcy> :) 17:17 -!- bcman [~quassel@192.252.212.36] has joined ##taproot-activation 17:18 < gwillen> does anybody else have a weird rendering issue with the text graph in https://taproot.watch/index.txt 17:19 < gwillen> I think it may be chrome's fault, it seems to be rendering two different versions of the character U+25A1 White Square 17:21 -!- faketoshi [~quassel@192.252.212.45] has quit [Ping timeout: 260 seconds] 17:21 < Emcy> what kind of two different versions 17:21 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation 17:22 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 17:22 < Emcy> green and pink? 17:22 < gwillen> on the lines where the white square is the first character, it renders all instances of that character much smaller than the black square 17:23 < gwillen> on the lines where the black square is the first character, it renders them all the same size 17:23 < gwillen> this is on OS X, which I guess is probably relevant because font rendering stuff. Also obviously this is dumb and doesn't matter at all, I was just curious. :-) 17:24 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 265 seconds] 17:24 < Emcy> on windows the white square is always smaller, on linux its the same size 17:25 < gwillen> haha, apparently on mac they split the difference XD 17:25 < Emcy> looks like it 17:25 < gwillen> I do wonder if it's actually intentional, like the size of the character is poorly-defined, so they have some heuristic to try to make it look right 17:26 < gwillen> 25A2 White Square With Rounded Corners has the opposite problem, it's slightly too big if it's the first thing on the line, but matches the size of the black square if it shows up later. 17:26 < gwillen> (I'm just trying stuff for the lulz) 17:31 < Emcy> tahts real weird 17:32 < Emcy> try a different chrome browser 17:32 < Emcy> i get different rendering on the same browser on 2 OSes 17:36 < queip> congrats un apparently upcoming activation 17:36 < queip> in case if we ever need a logo tho https://files.catbox.moe/g44d4e.png 17:46 < Emcy> lol 18:00 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Remote host closed the connection] 18:00 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined ##taproot-activation --- Log closed Tue May 18 00:00:58 2021