--- Log opened Sat Feb 27 00:00:41 2021
01:00 -!- ensuremoonrise[m [ensuremoon@gateway/shell/matrix.org/x-fwjmwmbhbnrheutl] has quit [Quit: Idle for 30+ days]
01:25 -!- waxwing_ is now known as waxwing
01:26 -!- waxwing [~waxwing@193.29.57.116] has quit [Changing host]
01:26 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined ##taproot-activation
02:41 -!- pox_ [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
02:44 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 268 seconds]
03:42 < AaronvanW> So yeah, it's obviously a tiny, bitcoin-twitter specific sample, but this poll suggests that a majority of users (70%) would prefer Bitcoin Core to release with LOT=false: https://twitter.com/AaronvanW/status/1365032903986536452
03:43 < AaronvanW> Even though a small majority(again, tiny, bitcoin-twitter specific sample) would want to run LOT=true themselves.
04:52 < AaronvanW> That's consistent with my earlier poll, by the way: https://twitter.com/AaronvanW/status/1364665786028154883
05:14 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
05:15 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##taproot-activation
05:34 < pox_> Seems like full consensus about the signaling parameters isn't going to be reached. If lot=false is released, there's a minority that will build and run lot=true. Either this intransigent minority gets to dictate the default for the rest, or the majority sticks with lot=false and assumes it'll be a moot point since it won't come to it, anyway, because miners are likely to signal earlier.
05:37 < pox_> In any case, continuing the back and forth seems counterproductive. It's less a matter of strategy at this point and more of principle (miners shouldn't be able to delay under any circumstances vs. no reason to push miners around since they're not any less of a bitcoin user).
05:39 < pox_> At a certain point the community is just bike shedding and the appearance is that the project is getting mired in committees that can't reach conclusions.
05:40 -!- CubicEarth_ [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 246 seconds]
05:41 < pox_> Whatever happens with true vs. false, in 1y we'll all be wiser when we see how it pans out, so the default for the next soft fork should be obvious.
05:41 < pox_>  * by then
05:43 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##taproot-activation
06:38 <@michaelfolkson> There is a ##uasf channel for the lot=true Taproot activation implementation https://github.com/BitcoinActivation/bitcoin
06:41 <@michaelfolkson> I think there will be a PR (at some point) on Core implementing default lot=false with no lot=true logic. But I think the place to discuss that future PR will be ##bitcoin-core-dev
06:42 <@michaelfolkson> I guess this channel will be left for anything that isn't specific to the Core PR or the UASF lot=true implementation
06:43 <@michaelfolkson> * #bitcoin-core-dev (only one #)
07:20 < luke-jr> michaelfolkson: don't know why you want to push for consensus breaks
07:29 -!- cdecker_ [~cdecker@mail.snyke.net] has left ##taproot-activation ["The Lounge - https://thelounge.chat"]
07:37 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Ping timeout: 276 seconds]
07:45 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
07:50 <@aj> https://gist.github.com/ajtowns/fbcf30ed9d0e1708fdc98a876a04ff69#file-repeated_trials-py has a script to give feel for how much variance there is between threshold and hashpower required to reach the threshold -- with 26 trials (ie a year's worth of retarget periods), and a 90% threshold over 2016 blocks, 86.3% hashrate is almost certain to fail, 88.6% hashrate has a 50/50 chance, and 89.8%
07:50 <@aj> hashrate is almost certain to succeed
07:54 -!- mode/##taproot-activation [-o aj] by ChanServ
08:01 < nickler> aj: interesting. I hadn't considered this when we discussed the 90% threshold. But that variance would make it close enough to 90% I think.
08:05 < luke-jr> indeed
08:06 < luke-jr> the real risk re hashrate however is the 6-block confirmation after activation
08:14 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
08:14 -!- pox_ [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 268 seconds]
08:14 -!- pox__ [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
08:15 -!- pox_ [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
08:19 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 268 seconds]
08:19 -!- pox__ [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 268 seconds]
08:27 -!- pox_ [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 268 seconds]
08:41 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
09:16 < jeremyrubin> luke-jr: BIP8 question
09:17 < jeremyrubin> If LOT=true only starts forking after the threshold is impossible, isn't that a little incentive incompatible?
09:18 < jeremyrubin> As a theoretical forking miner, would one not prefer to begin orphaning blocks earlier and "save" the spare capacity towards the end of the signaling period?
09:20 < jeremyrubin> e.g., if you start trying to fork early in the period, and fail to reorg a few non-signal block, you'd learn that you need more hashrate to do accomplish activation with full consensus, but still have time to coordinate that
09:20 < jeremyrubin> but if you wait to reject until you've spent all your budget then you have to continue building the fork
09:23 < jeremyrubin> Also
09:24 < luke-jr> I don't understand what you mean
09:24 < jeremyrubin> Ok maybe I can explain it more simply
09:24 < jeremyrubin> Assume you're running LOT=true and you prefer to keep as much hashrate on your chain as possible
09:25 < jeremyrubin> you reach block 15 in the final 'must signal' period, and it doesn't signal for Taproot, but all others have signalled
09:25 < jeremyrubin> should you attempt to reorg it?
09:25 < jeremyrubin> Here the answer might be 'No' because it *seems* like taproot has > 90%
09:25 < jeremyrubin> but let's say the 5th block in the period doesn't signal
09:25 < jeremyrubin> now if you (naively) infer that 20% won't signal
09:26 < jeremyrubin> should you attempt to orphan that block?
09:26 < jeremyrubin> I'd say it is in your game theoretic interest to attempt to
09:27 < jeremyrubin> because if you succeed, then it is one less against your 'fork count', which leads to some level of network disruption you prefer to avoid
09:27 < jeremyrubin> and you will either have to reorg it now or later
09:28 < jeremyrubin> ie, by reorg attempting earlier you have more probability of maintaining full consensus
09:28 < luke-jr> you're assuming miners intend to create invalid blocks
09:30 < jeremyrubin> Well I think it's certainly safer to signal than not to!
09:31 < jeremyrubin> I think you're more or less saying the above is ex false quod libet
09:31 < jeremyrubin> but I don't quite think it is, a chainsplit is certainly possible
09:35 -!- jonatack [~jon@37.170.73.95] has joined ##taproot-activation
09:36 < luke-jr> only if miners choose to split
09:36 < luke-jr> your behaviour is strictly more likely to see such a split I think
09:38 < jeremyrubin> Ah, well miners don't have to commit to a sustained orphaning
09:38 < jeremyrubin> e.g., like selfish mining
09:39 < jeremyrubin> If they fail to orphan after effort amount E, then they build on the 2 block tip
09:39 < jeremyrubin> but suppose LOT = True has 20% hashrate on it
09:40 < luke-jr> eh? that's very different
09:40 < luke-jr> you're saying a previously invalid chain can become valid⁇
09:40 < jeremyrubin> No
09:40 < luke-jr> that's a whole new can of worms :|
09:40 < jeremyrubin> essentially selfish mining but for signaling
09:40 < jeremyrubin> it increases the orphan rate
09:41 < jeremyrubin> but decreases the probability of a chain split
09:41 < luke-jr> I don't see how
09:41 < jeremyrubin> e.g. with 20% you get about a 5% boost in effective hashrate
09:42 < jeremyrubin> think of a miner with 20% hashrate
09:42 < jeremyrubin> a non signal block comes
09:42 < jeremyrubin> they don't recognize it
09:42 < jeremyrubin> it gets built on by another signaling block
09:42 < jeremyrubin> they build on the non signal block
09:42 < jeremyrubin> another non signal block
09:43 < jeremyrubin> they attempt to orphan it.... 1/5 of the time they succeed in crating an alternative
09:43 < luke-jr> I don't follow
09:43 < luke-jr> [17:42:23] <jeremyrubin> a non signal block comes <-- is that block valid or invalid?
09:43 < jeremyrubin> 1/5 of the time (big assumption: 1st seen rule is in play so they are the only miner mining it)  they will build a 2 block lead on their new block
09:43 < jeremyrubin> luke-jr: it is valid
09:44 < luke-jr> then they must recognise it
09:44 < jeremyrubin> No they don't have to? They can choose to mine on the stale tip
09:44 < jeremyrubin> 5% of the time they can get a 2 block lead and orphan it
09:44 < luke-jr> then it isn't valid
09:45 < luke-jr> validity = recognition
09:45 < jeremyrubin> They are manipulating their hashrate via a selfish mining attack (costing them money mind you) to reduce the chance of a split
09:45 < jeremyrubin> This action reduces the effective hashrate % required to activate taproot by 5% to 85%
09:46 < luke-jr> LOT=True reduces it to 0% already :P
09:47 < jeremyrubin> Maybe let's start with a simpler slightly unrelated question: assuming an unknown mixture of LOT=true and LOT=false, is a LOT=false miner better off with the first seen rule or first seen prefer signaling blocks rule?
09:47 < luke-jr> no code exists that would choose the latter
09:48 < jeremyrubin> ignore the code question, I'm just talking about profitability for the theoretical next time bip8 gets used
09:49 < jeremyrubin> if i see both, the chances that my block gets built on is greater (assuming LOT=true > no taproot code at all) to mine on the signaling block
09:49 < jeremyrubin> (plus as LOT=false + signaling... I want taproot to activate)
09:55 < luke-jr> but if you wanted Taproot to activate, you'd be running LOT=True ;)
09:56 < luke-jr> LOT=False just puts you in the position of failing to attain any consensus
09:56  * luke-jr needs to finish a writeup on all this for hte ML :/
09:58 < luke-jr> jeremyrubin: anyway, if I understand your idea correctly, it DOES amount to making invalid blocks become valid with sufficient conditions in subsequent blocks being met; and would be a huge can of worms to implement even if a good idea
09:58 < luke-jr> remember that full nodes must reject the same blocks miners reject, even if short-term
10:00 < jeremyrubin> it's equivalent to the selfish mining, but just triggered on blocks that don't signal
10:01 < jeremyrubin> so IDK if miners have code to do that currently -- there's been some speculation yes, some speculation it's just increased latency due to FIBRE
10:02 < luke-jr> selfish mining is an attack because full nodes don't reject the blocks
10:02 < luke-jr> for an actual consensus rule, full nodes need to enforce the same as miners
10:02 < jeremyrubin> some would say LOT=true is an attack too
10:02 < jeremyrubin> ;)
10:03 < luke-jr> so the code for this would be complex and need careful review, PLUS it's unlikely to ever matter..
10:06 < luke-jr> that would be a lie ;)
10:06 < luke-jr> LOT=true full nodes all enforce the same rules as LOT=true miners
10:06 < luke-jr> the only way it could be an attack, is if ALL softforks are attacks
10:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
10:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
10:33 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation
11:20 -!- jonatack [~jon@37.170.73.95] has quit [Ping timeout: 246 seconds]
11:20 -!- jonatack_ [~jon@37.172.209.215] has joined ##taproot-activation
11:44 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
12:30 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection]
12:31 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
12:53 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 265 seconds]
14:16 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
15:29 -!- stortz [bb3fa187@187.63.161.135] has quit [Quit: Connection closed]
17:07 -!- jonatack_ [~jon@37.172.209.215] has quit [Ping timeout: 276 seconds]
17:30 -!- brg444 [uid207215@gateway/web/irccloud.com/x-ywoijfaymppijeyx] has joined ##taproot-activation
17:36 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 246 seconds]
17:53 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Quit: Lost terminal]
17:57 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined ##taproot-activation
17:59 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
19:09 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
19:12 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 276 seconds]
20:04 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 276 seconds]
20:48 -!- livestradamus [~quassel@unaffiliated/livestradamus] has quit [Quit: I'm out.]
20:48 -!- livestradamus [~quassel@unaffiliated/livestradamus] has joined ##taproot-activation
21:13 -!- roconnor [~roconnor@host-104-157-194-235.dyn.295.ca] has quit [Quit: Konversation terminated!]
21:58 -!- brg444 [uid207215@gateway/web/irccloud.com/x-ywoijfaymppijeyx] has quit [Quit: Connection closed for inactivity]
22:50 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
22:52 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
--- Log closed Sun Feb 28 00:00:43 2021