--- Log opened Fri Feb 19 00:00:37 2021
00:25 -!- ensuremoonrise[m [ensuremoon@gateway/shell/matrix.org/x-jmrwwjyvkvilovot] has quit [Ping timeout: 240 seconds]
00:26 -!- mitjavoll[m] [mitjavollm@gateway/shell/matrix.org/x-zszrofkcdwmtfrcy] has quit [Ping timeout: 246 seconds]
00:26 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-ygwwwiqyielnmezr] has quit [Ping timeout: 244 seconds]
00:26 -!- amptwo [segwitmatr@gateway/shell/matrix.org/x-ynpwvsgwktrqaqpi] has quit [Ping timeout: 264 seconds]
00:27 -!- CubicEarth_ [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds]
00:27 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##taproot-activation
01:18 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
01:18 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
01:20 -!- ensuremoonrise[m [ensuremoon@gateway/shell/matrix.org/x-dzqbbbuyvqbgffes] has joined ##taproot-activation
01:31 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-sreimgnorbkuxepu] has joined ##taproot-activation
01:31 -!- amptwo [segwitmatr@gateway/shell/matrix.org/x-knsbdhgdixuiqqhc] has joined ##taproot-activation
01:31 -!- mitjavoll[m] [mitjavollm@gateway/shell/matrix.org/x-olbvygonpbnoajyr] has joined ##taproot-activation
01:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:14 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation
02:15 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 268 seconds]
02:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
02:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:57 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
02:57 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
03:16 <@michaelfolkson> A reminder that we have a meeting to do a code review meeting of https://github.com/bitcoin/bitcoin/pull/19573 on Tuesday. It would be great to have a focus on that at least until Tuesday
03:17 <@michaelfolkson> (Feel free to discuss whatever you want obviously but ideally this PR would be the focus)
04:01 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
04:04 < maybehuman> I guess one question would be if it's really wise to replace bip9 wholesale. It may have some shortcomings, but with bip8 it seems we're unable to even nail down the activation parameters. So maybe keep bip9 as an option?
04:05 < aj> maybehuman: there's no benefit to bip9 over bip8 with lockinontimeout=false
04:06 < maybehuman> aj: except that with bip9 you don't even have to discuss lot
04:06 < maybehuman> the paradox of choice. Or something
04:07 < aj> maybehuman: you'd have the same debate with different terms to decide on bip9 as you'd have to decide on bip9 with lockinontimeout=false
04:08 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-ijxwyxgobnnnxfzx] has quit [Remote host closed the connection]
04:08 -!- rdymac [uid31665@gateway/web/irccloud.com/x-ztsaembyqgmaqhzd] has quit [Remote host closed the connection]
04:08 < aj> that last bip9 should be bip8
04:11 < maybehuman> the thing is, this lot debate is really not productive, and I think the existence of that parameter is a flaw in bip8
04:11 < aj> "this debate is not productive" -> <debates further>
04:13 < maybehuman> yes, its a catch-22 :-)
04:14 < maybehuman> Let me put it this way: bip8 started out as an extension of bip9. Many of the things proposed in there are uncontroversial improvements. lot cannot be said to be uncontroversial. So maybe just take the stuff everybody agrees on and keep the rest as it was?
04:16 < aj> "whether x should be A or B is controversial. to avoid controversy, nobody should have the option of x ever being B" -- you see how that's not actually likely to be less controversial, surely?
04:17 < aj> bip8 started out as a the support details for bip149 which was a new deployment for segwit to be done after the first one failed which would not allow failure
04:17 < aj> https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki
04:18 < aj> it got generalised to allow it to either work that way or work in a similar way to bip9 relatively recently (~june last year?)
04:19 < maybehuman> text-wise this was the earliest draft I could find: https://gist.github.com/shaolinfry/0f7d1fd22743bb966da0c0b1682ea2ab/b7c66bd6e06b35903427528407987882daa46fa7
04:20 < aj> that's the bip148 approach
04:20 < maybehuman> wrt "less controversial" sure, that will not go over smoothly. I'm just afraid it's a bit like merging a flamewar generator
04:22 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-znbjqmcnlwszszsx] has joined ##taproot-activation
04:22 < aj> people have different opinions on what's the best thing to do, it happens
04:22 -!- rdymac [uid31665@gateway/web/irccloud.com/x-packtskhhrmcgpbc] has joined ##taproot-activation
04:22 < aj> if it's over something important and you can't find a way to let everyone have their cake and eat it too, you get controversy and flamewars
04:23 < maybehuman> exactly, they have different opinions. So why have a mechanism that requires them to all have the same opinion?
04:23 < aj> because that's what "consensus" means
04:25 < darosior> maybehuman: reasoning like this makes me think of the "everything is fine" meme :) You don't just hide the issue and pretend there is no issue. I think we need to have these debates in order to move forward and set a precedent for post-Segwit soft forks. It's healthy to be debating core issues
04:26 < maybehuman> well, if it's a one-time debate ok, but for that it doesn't need to be a setting in the bip
04:29 < aj> you can't have a meaningful debate over a technical subject without exactly defining what you mean by the different approaches. exactly defining what an approach means *is* writing up a bip. if it weren't a parameter in one bip (bip8 lot=true/false), it'd be two bips (eg bip8 and bip9).
04:29 < maybehuman> also, my point was more, you have some code you want to replace (bip9 in the pr). However, the replacement or parts of it are controversial. Wouldn't the conservative thing to do be to keep the status quo then?
04:29 < aj> (or bip148 vs bip149)
04:31 < aj> "i think we should step left off the train tracks" "no, i think we should step to the right" "left" "right" narrator: to avoid further controversy, they stayed in the middle of the train tracks for the rest of their life
04:32 < maybehuman> are we on train tracks?
04:32 < aj> some would argue that sticking with bip9 is pretty much that, yes
04:33 < aj> the argument being that we got very lucky that bip148/bip91 didn't result in a huge disaster with millions of dollars of losses; and that next time we won't be so lucky
04:34 < maybehuman> afaict the argument relies on lot true to avoid the disaster, right?
04:34 < aj> some argue that going straight to lockinontimeout=true is the way to avoid that. personally, the strongest argument for me is that bip8/lockinontimeout=false means we don't have the time-vs-height discrepency from bip9 that made bip148 particularly rushed so is a strict improvement, even if we might still be standing too close to those train tracks for comfort
04:35 -!- reallll is now known as belcher
04:41 < maybehuman> yes, I think everyone agrees that heights are better than time. Which is why I was saying, you could also just take that part and leave the disputed ones out until the dust settles
04:42 < aj> so given people dispute the value of lockinontimeout=false, that could mean only having lockinontimeout=true
04:42 < maybehuman> well, there's also arguments against true, the matter is just not settled yet
04:42 < aj> certainly that was what "implementing bip8" would have meant this time last year
04:43 < aj> right, which is why "X is disputed, therefore don't allow X" is a fairly specious argument
04:45 < maybehuman> it's more "don't change your code to support something disputed"
04:46 < aj> that takes you back to staying on the train tracks because you can't decide whether to go left or right
04:47 < maybehuman> I must admit I haven't followed that closely, but I had the impression that bip9 vs bip8 was decided mostly by the height issue
04:47 < darosior> aj: what is your opinion on starting with LOT=true ?
04:47 < aj> and hey -- deer in the headlights is a real thing! making decisions in consensus systems is hard
04:47 < maybehuman> I guess I just don't see any urgency
04:48 < maybehuman> we have a mechanism that worked before (maybe due to luck), we have some uncontroversial improvements, so there's an iterative improvement
04:49 < belcher> MASF also worked before you could say
04:49 < belcher> what worked before is a tricky argument because we learn new things
04:49 < aj> darosior: i expect either will work out fine at this point
04:50 < belcher> i fear a third option now, that if core cant agree on the value of LOT then the soft fork wont go ahead at all
04:50 < aj> maybehuman: we've tried a bunch of mechanisms, discovered flaws in each of them, and tried to come up with new mechanisms that address those flaws
04:50 < darosior> aj: do you have a personal preference?
04:50 < belcher> after all the network protects nearly $1 trillion in value, thats a lot of put at risk of a possible chain split
04:52 < aj> darosior: if everyone crowned me king for a day and swore to follow my decision with no complaints, i'd go for a 2 year timeframe with lockinontimeout initially false, with a hidden config parameter allowing users to override it (ideally with some sort of safety device so it wouldn't get set accidently/carelessly, if such a safety device is even possibly)
04:54 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
04:55 < darosior> aj: thanks. I believe my arguments in previous meeting(s) for doing a LOT=true after a LOT=false to activate both was weak since we agreed upon 1y. Was thinking about 1.5y (with switching to true after say 6 months if bad will from miners is demonstrated) but 2y is very fine too
04:56 < darosior> Why a hidden config instead of a second release ? (since i think you don't need everyone to switch to true in the forced attempt?)
04:56 < belcher> do supporters of LOT=true realize that this is a UASF, so like in 2017 you need to show that enough of the economy supports it, note that its different from supporting taproot itself, you have to show support for a UASF
04:57 < belcher> and back in 2017 segwit was very do-or-die, fee were very high with lightning network not really possible without segwit, and asicboost was discovered which made people fear miner centralization..... taproot doesnt have any of that, its a nice to have but bitcoin works perfectly well today, would enough of the economy risk a chain split from a UASF just to get taproot? im not sure, we'd need to see evidence either way
04:58 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
04:58 < aj> belcher: at 50k, every block reward is ~$300k so a 6-block reorg means some miners have lost $1.8M in foregone income. to get a chain split, you probably have to mine an additional week's worth of blocks at "current" difficulty before both sides of the split retarget, which probably wastes ~1000 * $300k * 50% ~= $150M (50% to account for electricity costs being well under block reward these days,
04:58 < aj> aiui)
04:59 < belcher> aj isnt that an argument against a UASF? because if the worst happens then ~$1.8M would be lost
04:59 < darosior> belcher: +1(00), i think most would get behind an UASF if miners try to prevent activation of Taproot but i highly doubt they would a proof of such behaviour
05:00 < belcher> the worst happens if miners dont all come to the same conclusion about what the economy wants, and they mine different chains and end up losing money, and users might end up losing because transactions get reversed
05:00 < aj> belcher: i think it's an argument that miners will adapt to a UASF pretty quickly if needed to avoid that outcome; likewise that a split is unlikely
05:02 < belcher> aj they would adapt if they thought enough of the economy wanted it... last time in segwit we had the hats, we had massive drama on all the social media, conferences, a ~2 year history of drama... for taproot we'd have none of that, lightning works today, why would a bitcoin business risk a UASF when from their point of view everything is fine? even the price is at near-ATH
05:02 < aj> belcher: having the lockinontimeout=true code already in the client also makes it very easy for miners to avoid that outcome -- at worst they (or their pool operator) needs to recompile their node and change a single false to true; not run a completely random UASF fork from somewhere that all the hat people think is awesome
05:03 < belcher> the hard part isnt the code, but the figuring out of what everyone else wants, and if you judge wrong then thats ~$1.8M at risk as you calculated
05:03 < belcher> as bluematt wrote on the mailing list, bitcoin is about coming to consensus, if thats at risk then many people would judge it safer to not attempt a taproot soft fork at all
05:04 < aj> belcher: the price was at ATH's during all the NYA/UASF controversy too?
05:04 < belcher> yes because it was likely the UASF would succeed, i remember the price pumping after asicboost was made public because it became even more obvious that it would work
05:05 < belcher> then after the UASF locked in the price doubled, some kind of relief rally you could say.... so obviously the market was nervous about the risk and bought when it all turned out okay... meaning the risk was real
05:05 < aj> belcher: $1.8M is what miners risk if they don't come to consensus amongst themselves; if you actually get a 6-block reorg, exchanges and the like have a good chance of losing much more than that, because attackers will notice miners aren't in consensus, and do double spends
05:06 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-ruscvhxdkxnvfepw] has quit [Remote host closed the connection]
05:06 < belcher> right, so its even worse than $1.8M at risk
05:07 < belcher> it would be best if the LOT=true people gave up and stopped trying to get economic nodes to run that, because what could happen is people could judge any taproot soft fork too risky and not even attempt it
05:07 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-zogsylksfifauupl] has joined ##taproot-activation
05:07 < belcher> i dont know why LOT=true supporters are so gung-ho about it when 90% of the miners said they'll activate taproot in a MASF
05:07 < belcher> you'll get nothing at all if you're not careful
05:08 < aj> exchanges are only at risk of doublespends if they're not running node software that's in-consensus; and they're generally not stupid, so by that view it should be far less than $1.8M at risk
05:08 < belcher> aj the million dollar question is what node is in-consensus
05:09 < belcher> the problem is that it will be hard to know
05:09 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
05:09 < aj> sure, but you can't answer that question purely in software (without wasting PoW to the tune of half a million or more, anyway)
05:10 < belcher> yep, its a coordination problem
05:10 < belcher> same as in 2017 with that UASF, but there the risk was worth it
05:11 < belcher> so how about this: in 2017 supporters of UASF went round to many bitcoin businesses and got them to support bip148, we got businesses like bitrefill, vaultoro, bittylicious saying they'll use a UASF node... so today LOT=true supporters who want a UASF will have to do the same
05:11 < aj> err, well, you can answer that question purely in software if >90% of hashpower is in agreement within a year, which is what we hope/expect will happen
05:11 < belcher> show me the businesses that support LOT=true and then that will be convincing that it is safe
05:12 < belcher> (bittylicious was one of the top OTC exchanges in the UK which i used many times, so back in 2017 i found their support in particular very convincing)
05:14 < aj> yeah, i'd find it hard to ask businesses for support -- there's no demonstrated need for it yet (maybe there will be in six months), and the implementation isn't reviewed or merge (though hopefully it will be soon enough)
05:15 < aj> but i think starting off with lot=false and changing it to true later if needed is fine, so...
05:16 < belcher> yes i agree
07:26 < luke-jr> [12:14:37] <maybehuman> Let me put it this way: bip8 started out as an extension of bip9. Many of the things proposed in there are uncontroversial improvements. lot cannot be said to be uncontroversial. So maybe just take the stuff everybody agrees on and keep the rest as it was? <-- you're implying LOT=false is agreed on; it isn't
07:29 < zmnscpxj_> Make a prediction market for LOT=true/false. Let a BTC be split into T and F coins. If the taproot is miner-activated you can merge T and F coins back into a BTC. If taproot fails miner activation then if a LOT=true chain exists the T coins are convertible to that and the F coins are convertible to the LOT=false chain.
07:29 < zmnscpxj_> That should help ask the economic majority
07:30 < luke-jr> zmnscpxj_: that implies F is coherent at all
07:30 < zmnscpxj_> of course, such a system would probably be most easily implementable as a custodial exchange, so there is third-party risk that some economic powerhouses may not consider safe enough, sigh
07:30 < luke-jr> zmnscpxj_: you can't have a functioning coin or exchange thereof when its chain is being regularly wiped out
07:31 < luke-jr> or more likely doesn't exist at all
07:31 < zmnscpxj_> then the economy should value F coins according to that metric
07:31 < luke-jr> zmnscpxj_: so I sell you my F coins on the exchange, but then the reorg returns those coins to me. What now?
07:32 < luke-jr> (or perhaps moves those coins to random third party)
07:32 < zmnscpxj_> Then I made a mistake buying F coins from you and my LOT=false position was wrong and you have proven your argument
07:32 < luke-jr> what if you sold those F coins already?
07:32 < zmnscpxj_> basically, "put your money where your mouth is"
07:32 < zmnscpxj_> then whoever bought those coins made a mistake, etc.
07:33 < luke-jr> lol
07:33 < zmnscpxj_> If the position is considered true by most economic actors then the F coin will drop in value to 0
07:33 < zmnscpxj_> just like the S2X coins did in the past
07:34 < zmnscpxj_> Personally I think for *taproot* at least you can pick LOT=coin_toss() and it will still activate, *shrug*. But I may be too hopeful
07:41 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation
07:42 < zmnscpxj_> of course with LOT=coin_toss() the debate then shifts on the best way to implement a decentralized coin_toss() function, with accompanying nerd debates, so never mind LOT=coin_toss(), let us just debate LOT=true/false.
07:46 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
07:54 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
08:01 -!- criley [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation
08:10 -!- criley [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has quit [Quit: Ping timeout (120 seconds)]
08:10 < robert_spigler> If people are so certain miners will activate taproot, there is no reason /not/ to run LOT=true
08:19 -!- maybehuman [d95ef591@pd95ef591.dip0.t-ipconnect.de] has joined ##taproot-activation
08:20 < maybehuman> luke-jr: No, I'm not implying it is agreed on, I'm saying it's what de facto exists in Core right now
08:23 < maybehuman> robert_spigler: I think it's mostly about the precedent it creates (and some would probably argue that true might lower acceptance)
08:23 < luke-jr> maybehuman: as dead code
08:24 < maybehuman> Still though
08:25 < stortz> is there no way to compromise between the two, LOT=false(timer until X then flip to true) ?
08:25 < robert_spigler> maybehuman: the precedent is that we make it clear miners are only for coordination, not for voting
08:26 < stortz> or does that defeat the propose equally
08:26 < zmnscpxj_> stortz: given that LOT only takes effect at the end of the timeout, the timered version is no different from LOT=true
08:26 < stortz> that's true
08:26 < robert_spigler> stortz: that's the equivalent of LOT=true, except allows for mixed networks and messy activation (and miners thinking they have the power to vote/veto)
08:27 < maybehuman> robert_spigler: I think harding articulated the precedent thing pretty well, no need to go over it again
08:27 < stortz> yea, that only makes me more certain of LOT=true being the best option and not as forced as it seems
08:28 < robert_spigler> maybehuman doesn't mean he's right
08:28 < maybehuman> yeah, just saying, no need to repeat it again
08:29 < robert_spigler> :thumbs up:
08:29 < zmnscpxj_> thing is, we have consensus taproot=good, we just do not have consensus on LOT=*, it seems very sad to me that Taproot fails simply because we cannot agree on LOT=*
08:29 < luke-jr> so about that code review…? :P
08:30 < luke-jr> zmnscpxj_: thankfully, softforks do not require consensus
08:30 < zmnscpxj_> just requires >51% hashpower
08:30 < stortz> what we're trying to minimize is the loss of number of nodes lost in the process
08:30 < luke-jr> zmnscpxj_: no
08:31 < stortz> I just typed loss twice
08:32 < robert_spigler> they do require economic majority of nodes enforcing
08:32 < luke-jr> zmnscpxj_: and that misconception is another reason to reject LOT=false ;)
08:33 < zmnscpxj_> luke-jr: disagree, as no economic node will remain on a chain with low hashpower.  On the other hand no miner will remain on a chain with little economic value, so... *shrug*
08:34 < luke-jr> zmnscpxj_: why not?
08:34 < maybehuman> What I still don't get about the lot=true position is why have the option for false in the bip at all then? The argument seems to be that false is just universally bad. So why give the option and then tell everybody that chooses it that they are making a mistake?
08:34 < luke-jr> "low hashpower", keep in mind, is simply "hashpower Bitcoin had not long ago", and centralised, so doesn't even provide most of the security it should
08:35 < luke-jr> maybehuman: if we have consensus for LOT=true, I would be proposing to remove the option
08:35 < maybehuman> luke-jr low hashpower also means only one block an hour
08:35 < luke-jr> maybehuman: not necessarily
08:35 < maybehuman> and all the drama that that creates
08:35 < stortz> maybehuman luke said he regrets including the option now
08:35 < zmnscpxj_> luke-jr: precisely why no economic node will want a chain with hashpower "Bitcoin had not long ago and centralized"
08:36 < maybehuman> even though that seems to be a bit rewriting history
08:36 < luke-jr> zmnscpxj_: that makes no sense
08:36 < luke-jr> zmnscpxj_: Nothing has improved since then
08:36 < maybehuman> at least to me it looked like from the beginning uaversionbits proposal was meant to be an optional addon
08:36 < zmnscpxj_> luke-jr: and it is still substantially worse to go from the *current* hashpower to a *lower* hashpower, is the point
08:36 < luke-jr> zmnscpxj_: no, it isn't.
08:37 < zmnscpxj_> luke-jr: or maybe we are violently agreeing, what were you pointing out exactly anyway?
08:37 < luke-jr> zmnscpxj_: simply that there is no problem for economic nodes if former miners stop mining
08:37 < luke-jr> zmnscpxj_: but the problem for miners remains, so they will keep mining
08:38 < luke-jr> if it made sense for miners to attack light wallets, they could do so today already
08:38 < zmnscpxj_> luke-jr: users need confirmations. this is why consensus is needed.
08:38 < luke-jr> zmnscpxj_: they will still happen
08:38 < luke-jr> even if ALL the miners were to defect, a simple PoW change can fix that
08:38 < luke-jr> and again, the miners won't
08:39 < zmnscpxj_> yes, but much more slower, which reduces utility etc. etc. but as you point out as well, miners will not want that as well, as it loses their income.
08:39 < luke-jr> not really; an hour or a day makes little difference, especially short-term
08:40 < luke-jr> if anyhting, perhaps it would drive Lightning adoption, which would be a good thing
08:41 < maybehuman> if the mempool is really full, Lightning would probably be susceptible to flood and loot, no?
08:41 < zmnscpxj_> yes, but a chainsplit would be very bad for Lightning, as two counterparties on the same channel may disagree about the blockchain state
08:42 < zmnscpxj_> maybehuman: I think not, as the block rate is lowered and all timeouts on LN are blockheight-based
08:42 < zmnscpxj_> maybehuman: so the lowered block rate cuasing the mempool fullness will also slow down all the timeouts that flood and loot is trying to exploit
08:42 < luke-jr> zmnscpxj_: that assumes there isn't economic support for the softfork
08:43 < maybehuman> I mean depends on whether they can bump their fees as much as regaulr onchain users
08:43 < luke-jr> also, blockchain state doesn't matter for Lightning that much?
08:43 < zmnscpxj_> luke-jr: yes, which in all likelihood does not apply to Taproot, we already know everyone pretty much agrees taproot=good && why is it not activated last year already
08:43 < luke-jr> either you have a route both parties find acceptable, or you don't..
08:43 < stortz> LOT=true should get economic and mining nodes to 99% in a year for sure
08:44 < zmnscpxj_> luke-jr: blockchain state matters if one chain looks higher than the other, then the senses of timeouts diverge and then there is possible confusion. but the default behavior is to drop onchain anyway and each can believe whatever it wants to believe
08:44 < luke-jr> zmnscpxj_: if you and your channel-peers don't agree, then you just close the channel cleanly
08:45 < zmnscpxj_> luke-jr: correct. but that implies a system shock to the LN layer, possibly leading to many little islands that cannot route to each other
08:45 < luke-jr> regardless, it is again only a problem if there is a lack of economic support, which is a very different scenario altogether anyway
08:45 < zmnscpxj_> luke-jr: we already saw that happen some years ago back when LN implementation were a lot less lenient about onchain fee disagrements
08:47 < zmnscpxj_> luke-jr: agree that only lack of economic support, which does not hold for Taproot, everyone pretty much agrees on taproot=good
08:48 < luke-jr> zmnscpxj_: do you know C++ ?
08:48 < zmnscpxj_> luke-jr: yes, I wrote CLBOSS in C++
08:49 < luke-jr> zmnscpxj_: I'm going to address comments on https://github.com/bitcoin/bitcoin/pull/19573 , but after that help review? ;)
08:49  * zmnscpxj_ is totally not off-topic shilling CLBOSS 
08:49 < zmnscpxj_> luke-jr: okay, but I have to go offline in a while for a GC cycle or two
08:55 -!- pox [~pox@141.226.243.49] has joined ##taproot-activation
09:04 < luke-jr> k, finished addressing previous reviews
09:04 < luke-jr> ready for new ones ;)
09:09 < maybehuman> out of curiosity: why is everything renamed to vbits instead of bip9 => bip8?
09:12 < luke-jr> maybehuman: why be more specific than it needs to be?
09:12 < luke-jr> BIP 8 (previously BIP 9) defines versionbits
09:13 < luke-jr> if someday we need a change for some reason, it doesn't make sense to have to rename everything again
09:24 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
09:27 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
09:39 -!- maybehuman [d95ef591@pd95ef591.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
09:57 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 246 seconds]
09:57 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
10:09 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]
10:10 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined ##taproot-activation
11:04 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 256 seconds]
11:36 -!- Netsplit *.net <-> *.split quits: andrewtoth_, luke-jr, wangchun_, fanquake, qubenix, roasbeef, bsm117532, stortz, sanketcell, robert_spigler,  (+91 more, use /NETSPLIT to show all of them)
11:40 -!- criley [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation
11:40 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
11:40 -!- Netsplit over, joins: jakesyl, raj_149, RubenSomsen, Abelian, dr_orlovsky, mblackmblack, sdaftuar, mol_, pox, stortz (+90 more)
11:48 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
12:12 -!- rdymac [uid31665@gateway/web/irccloud.com/x-packtskhhrmcgpbc] has quit [Quit: Connection closed for inactivity]
12:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
13:16 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
13:18 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
13:54 -!- sturles [~sturles@unaffiliated/sturles] has quit [Ping timeout: 265 seconds]
14:09 -!- stortz [bb3fa187@187.63.161.135] has quit [Quit: Connection closed]
14:14 -!- common [~common@unaffiliated/common] has quit [Ping timeout: 260 seconds]
14:20 -!- common [~common@unaffiliated/common] has joined ##taproot-activation
14:42 -!- molz_ [~mol@unaffiliated/molly] has joined ##taproot-activation
14:45 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 258 seconds]
15:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
16:12 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Quit: pinheadmz]
16:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
17:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
18:20 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Ping timeout: 272 seconds]
18:21 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined ##taproot-activation
18:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
18:51 < aj> zmnscpxj__: you should pronounce "CLBOSS" as "clubhouse" and try to convince people that it's the new new thing everybody's talking about
18:52 < zmnscpxj__> aj: good idea
20:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
21:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
21:08 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
21:08 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation
21:16 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 268 seconds]
21:37 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
21:39 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]
22:52 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 246 seconds]
22:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
23:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
--- Log closed Sat Feb 20 00:00:35 2021