--- 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