--- Log opened Thu Feb 04 00:00:35 2021
00:05 -!- liberliver [~Thunderbi@dynamic-089-012-226-086.89.12.pool.telefonica.de] has joined ##taproot-activation
00:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
00:55 -!- liberliver [~Thunderbi@dynamic-089-012-226-086.89.12.pool.telefonica.de] has quit [Ping timeout: 276 seconds]
00:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
00:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
01:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
02:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:31 < michaelfolkson> Cool, thanks virtu
02:45 < michaelfolkson> So there are still some open questions on lockintontimeout, activation threshold, start time etc. Which means we need to schedule a follow up meeting. How does Tuesday February 16th 19:00 UTC sound?
02:49 < michaelfolkson> Can luke-jr aj belcher dr_orlovsky anyone else who is popping up in this chat a lot let me know that time works for them with a y (Yes) or n (No)
02:53 < michaelfolkson> As luke-jr said yesterday we need to decide all the parameters we are going to propose to the mailing list
03:02 < aj> i guess for bip8, i'd phrase it as two recommendations: (1) when setting lockinontimeout=true, the timeout should be at least X months away to allow for that software to be deployed/configured. imo outside of an emergency, X should be >=6 months (as opposed to rusty's 3), but >=12 or >=18 months is plausible. (2) if deploying with lockinontimeout=false, timeout should be large enough to allow a
03:02 < aj> later redeployment following rule (1) with either the same or an earlier timeout
03:09 < aj> https://github.com/bitcoin/bips/pull/464 <-- i think segwit was 1 month between activation params merged and starttime (and only an extra few days before it actually hit STARTED). 0.13.1 was ~10 days after the bip got merged, so released-software->STARTED was about 23 days
03:39 < michaelfolkson> Sounds reasonable to me. Given Luke seems pretty strong on lockinontimeout=true would you be happy to go with 1) aj?
03:44 < aj> i think bip8 should document both alternatives; i don't think there'll be consensus for setting lockinontimeout=true initially for taproot in core personally
03:47 < michaelfolkson> Cool. Yeah luke-jr said similar yesterday re what Core had been willing to do in the past
03:48 < michaelfolkson> "Core has a history of failing to set LOT=true (BIP148) even when the community supports it"
03:50 < michaelfolkson> Again in the spirit of trying to move this along is it worth discussing what is viable from a Core perspective in the Core dev meeting later?
03:50 < michaelfolkson> Or do you think a proposal should be made on the mailing list before Core seriously looks at it?
03:54 < michaelfolkson> If there is no consensus for Core setting lockinontimeout=true presumably that leaves Luke's strong preference for it mute.
03:56 < michaelfolkson> I shouldn't keep saying Luke (it is a simplification). Others in the meeting this week expressed preference for lockinontimeout=true too
04:01 < aj> i think it should be possible to get the bip8 recommendations reasonably well sorted out; then do a poll like https://en.bitcoin.it/wiki/Segwit_support for a handful of major options
04:03 < aj> not sure what his current view is, but at one point he was in favour of core not setting activation params at all, iirc
04:10 < michaelfolkson> Hmm the meeting was hard but a poll like that seems it would be even harder. Good luck deciding which developers are listed and which developers aren't ;)
04:11 < michaelfolkson> At least with the meeting developers opt in by attending rather than the poll organizer deciding who should be asked and who shouldn't be asked
04:12 < aj> it's a wiki, people with accounts add themselves and any others that can be bothered sending their opinion who don't seem like pointless randos
04:12 < michaelfolkson> Oh ok, that sounds better
04:18 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
04:19 < michaelfolkson> So next step would be draft up the major options
04:19 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 268 seconds]
04:20 < michaelfolkson> BIP 8 parameters we don't have clear consensus on yet
04:20 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Ping timeout: 272 seconds]
04:20 < michaelfolkson> I still wonder if it is a touch overkill
04:21 < virtu> as to start time, I don't think getting to consensus will be that hard
04:21 < virtu> you should just ask for opinions during the next meeting
04:22 < michaelfolkson> No I don't either. I think everyone will just ACK something reasonable
04:22 < michaelfolkson> (Like SegWit precedent)
04:22 < michaelfolkson> And your data virtu
04:23 < virtu> as to LOT, I wish you the best of luck on how to figure that out ;-)
04:23 < michaelfolkson> In the absence of clear consensus on LOT=true it sounds like Core won't ship it. That was the view of both luke-jr and aj
04:24 < virtu> well, the pragmatic choice in that case would be to default to LOT=false
04:24 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined ##taproot-activation
04:24 < virtu> because I don't think that there's any chance we'll get clear consensus for true
04:26 < virtu> I'm sure you can work something out. So far you performance has been excellent
04:27 < michaelfolkson> Give Luke (and other LOT=true advocates) a chance in a meeting to try to obtain clear consensus on LOT=true
04:28 < michaelfolkson> If that doesn't happen I think we have to go to the mailing list with LOT=false
04:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
04:29 < michaelfolkson> I think if you put up a poll it definitely won't get clear consensus
04:30 < michaelfolkson> In which case it was a waste of time. And I don't think anything else will be difficult to get over the line
04:30 < virtu> luke-jr: maybe you can prepare points that support LOT=true; during the meeting, time was short, and you mostly stated true was better than false, but often you had no time to go into details as to why
04:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:30 < michaelfolkson> virtu: I can do this from what luke-jr has said so far in this channel
04:30 < virtu> michaelfolkson: I agree, a poll is not a good idea
04:31 < virtu> in fact, do we even have a pro/con list for true/false?
04:31 < virtu> since this seems to be the only controversial parameter
04:31 < michaelfolkson> I don't think so
04:32 < michaelfolkson> I'll add it to my to do list :)
04:32 < virtu> aj's survey contains thoughts on that
04:33 < michaelfolkson> Yeah and harding's proposals page https://en.bitcoin.it/wiki/Taproot_activation_proposals
04:33 < michaelfolkson> There is stuff to be added though from discussion on this channel
04:34 < virtu> just my opinion, but I think a list of pros and cons focused on true vs. false could be of merit
04:34 < michaelfolkson> Agreed
04:34 < virtu> because existing resources conflate the discussion with other parameters of the various proposals
04:35 < dr_orlovsky> michaelfolkson:  Tuesday February 16th 19:00 UTC will work for me
04:35 < michaelfolkson> Thanks dr_orlovsky
04:36 < michaelfolkson> I think I'll draft up that pros and cons list then virtu before I announce new meeting to the mailing list
04:36 < virtu> michaelfolkson: thanks for putting in all the work
04:36 < aj> if you can't get consensus when asking people, you can't get consensus
04:42 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Quit: jonatack]
04:43 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
04:48 -!- belcher_ is now known as belcher
06:21 -!- benthecarman [~benthecar@h133.169.131.40.static.ip.windstream.net] has joined ##taproot-activation
06:25 -!- benthecarman [~benthecar@h133.169.131.40.static.ip.windstream.net] has quit [Ping timeout: 264 seconds]
06:36 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
06:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
06:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
06:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
07:06 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Excess Flood]
07:07 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
07:20 -!- jonatack_ [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
07:22 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 258 seconds]
07:29 -!- jonatack_ [jon@gateway/vpn/airvpn/jonatack] has quit [Remote host closed the connection]
07:34 -!- jonatack_ [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
07:36 -!- nikitis [~nikitis@67.197.67.235] has left ##taproot-activation []
07:40 -!- jonatack_ [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 246 seconds]
07:45 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
07:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
08:17 -!- TechMiX [~techtux@2001:4649:61c8:0:6076:8428:1ecd:be09] has joined ##taproot-activation
08:26 < TechMiX> Hi, Could someone explain to me, from a strategic point of view, how BIP8 with lockinOnTimeout=false is any different from BIP9? So far, I know that technically they are different in terms of threshold mechanism, which in BIP8 the thresholds are in block heights instead of absolute times. luke-jr told me that BIP8 it's possible to add lockinOnTimeout even after the activation failed. Is this through a some configuration f
08:26 < TechMiX>  or like some mechanism? becuase if it's just some configuration, then we could do this BIP9 as well (change some constant in the code and recompile..) , what is the main benefit of BIP8(lockinOnTimeout=false) in comparison to BIP9? because to me they are pretty much the same. we can get into the same problem that we had with BIP9. please enlighten me. Thanks
08:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds]
08:40 < michaelfolkson> TechMiX: The transition diagrams on the BIPs are useful here I think
08:40 < michaelfolkson> This is BIP 9's transition diagram https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#state-transitions
08:41 < michaelfolkson> This is revised BIP 8's transition diagram https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#state-transitions
08:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
08:44 < michaelfolkson> We could do BIP 9 and then a UASF but the revised BIP 8 solution is cleaner
08:44 < TechMiX> michaelfolkson: Thanks, I saw those diagram before. I will check them again. but still if you set lockinontimeout=false, they are basically the same. aren't they?
08:45 < TechMiX> michaelfolkson: why is the revised bip8 with lockinontimeout=false cleaner than bip9+uasf? that's what I don't understand
08:48 < belcher> TechMiX strategically the block height vs timestamp means its easier for a bip148-style UASF later... if you remember the segwit activation expired in november but because bip148 could have lead to a big drop in hashrate it was required to put the bip148 activation way earlier in august
08:48 < belcher> thats not true for bip8 with block heights, because no matter how much the hashrate drops blocks will still get produced, so that means this kind of UASF is safer (and therefore any adversary is unlikely to try anything because they'll probably lose)
08:49 < belcher> also aside from UASF, i reckon using block heights is much cleaner, imagine if the halvening happened on the basis of timestamps rather than blockheights, it would pretty weird
08:53 < michaelfolkson> With BIP 9 you'd either need a new activation BIP for the UASF part or try to enact a UASF on top of a BIP 9 that hadn't reached a final FAILED state yet
08:53 < belcher> and of course its really worth re-empathising that theres no indication that any adversary would try anything, the situation today is totally different from 2017
08:55 < michaelfolkson> Highly unlikely but nonzero probability, right
08:56 < TechMiX> belcher: michaelfolkson: Thanks for the responses. but still, if we are going to do a UASF in case of a failure, why won't we just lockinontimeout?
08:57 < belcher> from the core dev's point of view, they want to get away from the perception that they de-facto control the protocol (see https://bitcoinhackers.org/@rusty/105664449877727721)
08:58 < belcher> so im guessing what will happen is bitcoin core itself will have LOT=false, and people who want to will run other code which has LOT=true
08:58 < belcher> remember in 2017 bitcoin core never implemented any bip148 code, it was entirely external to the core dev team
09:00 < TechMiX> it kinda makes sense. I understand their concern. got it. IMO we as the community should lot=true and endorse it
09:01 < michaelfolkson> RIght, an attempt to get best of both worlds. Miners activate when they are ready or if they start delaying for no reason users get involved
09:02 < michaelfolkson> Users, core dev team don't want to push miners if they don't need the push. But if they do there should be a mechanism
09:10 < AaronvanW> posted by reditor for two weeks: https://old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_will_be_able_to_veto/
09:26 < TechMiX> He has a point. but the thing about the core dev point of view is valid too. I think LOT should be a mandatory variable that users should confirm by themself and TRUE should be pre-selected
09:26 < belcher> to me it seems unlikely that the core devs will make it a configuration variable, they didnt want to for bip148
09:27 < belcher> see http://gnusha.org/bitcoin-core-dev/2017-05-25.log press ctrl+f "topic bip148"
09:27 < belcher> "Offering users settings we believe will harm third parties and the user is not 'neutral'."
09:27 < belcher> of course i dont want to second-guess the core dev team, i dont do much core dev myself so
09:27 < belcher> but the same argument against a configuration variable would probably apply today
09:28 < harding> I really don't like the idea of forcing users to have to choose variables.  I think the dev team, with their superior knowledge of the technical situation, should choose reasonable defaults.  For early taproot deployment, when there's reasonable belief that miners will activate taproot, LOT=false seems like a reasonable default to me.  If a few months pass and that proves not to be the case, a new minor version can be released with LOT=true.
09:30 < harding> Although I'm not opposed to making it a configuration variable from the start, I think for the same reason it doesn't need to be an option initially.  If it seems like the default should be changed, then the configuration variable can be introduced then in the same minor version.
09:46 < michaelfolkson> This sounds reasonable but I'm moving all over the place on this. So to play devil's advocate. Aren't we then in a situation of attempting to get consensus on when that minor version (LOT=true) should be released and putting Core in a place it doesn't want to be?
09:47 < michaelfolkson> Community knocking on Core's door demanding a LOT=true minor release?
09:49 < belcher> community is hard to measure
09:49 < belcher> the only time we need consensus on this is when deciding what code to put into bitcoin core
09:49 < michaelfolkson> Ideally all the decisions should be made now? Either we are happy to leave it a year in the worst case scenario. Or we decide now how long is acceptable until LOT is set to true
09:50 < belcher> people can always run whichever code they want, and maybe it would be good if more people got used to running non-core code (although in 2017 plenty of big bitcoin companies were happy with running the non-core bip148 client)
09:51 < belcher> rusty said 6 months of no activation without reasons https://bitcoinhackers.org/@rusty/105664449877727721 that seems a good time for me as well
09:51 < michaelfolkson> Yeah agreed
09:52 < michaelfolkson> Maybe we get consensus now on that. It is not included in software but there is a community understanding that if 6 months passes for no reason without activation there will be a Core minor release with LOT=true
09:53 < michaelfolkson> Take Core out of firing line. Just following what was agreed at the outset
10:00 < luke-jr> "luke-jr told me that BIP8 it's possible to add lockinOnTimeout even after the activation failed." <--- what?
10:02 < luke-jr> Devs have no business *deciding* - only implementing what the community has decided already; if Taproot is that, there is no basis for LOT=false
10:09 < virtu> I disagree
10:10 -!- TechMiX [~techtux@2001:4649:61c8:0:6076:8428:1ecd:be09] has quit [Read error: Connection reset by peer]
10:11 -!- TechMiX [~techtux@2001:4649:61c8:0:6076:8428:1ecd:be09] has joined ##taproot-activation
10:11 < virtu> it's an unnecessary risk; hence it should only be used when necesseary
10:11 < michaelfolkson> Maybe the community decides they want a lot=false minor version and then a lot=true minor version after 6 months (if needed, worst case scenario)
10:12 < michaelfolkson> If the community decides that as a halfway house devs aren't making any decisions
10:12 < michaelfolkson> Devs are following community wishes
10:12 < luke-jr> virtu: huh? LOT=false is the risk
10:12 < TechMiX> luke-jr: Sorry If I misread your words, this was what you said: 10:52 < luke-jr> the ability to set lockinontimeout=true later, and using block heights instead of clock time (http://gnusha.org/taproot-activation/2021-02-02.log)
10:12 < virtu> luke-jr: no, LOT=true is the rosk
10:12 < luke-jr> michaelfolkson: that's the same mess as 2017
10:12 < virtu> *risk
10:13 < virtu> luke-jr: your statements are lacking information
10:13 < virtu> with LOT=false, there's a risk of delayed activation
10:13 < luke-jr> TechMiX: later still needs to be prior to the last activation window
10:13 < virtu> with LOT=true, the risk is a chain split
10:13 < luke-jr> virtu: no
10:13 < virtu> I prefer the former risk to the latter
10:13 < luke-jr> LOT=false risk is chain split
10:13 < luke-jr> LOT=true has no such risk
10:14 < michaelfolkson> Whatever the default is set in Core LOT=true or LOT=false users can change it to a non-default
10:15 < michaelfolkson> So both could plausibly result in a chain split
10:15 < TechMiX> luke-jr: Ok, got it.
10:16 < belcher> LOT=true does have risk of chain split, which would happen if not enough miners signal by the end
10:16 < luke-jr> michaelfolkson: needing to change it creates risk
10:16 < luke-jr> michaelfolkson: it gives the impression that it's a decision; it's hard for most users who only use GUI; etc
10:17 < luke-jr> belcher: no, miners would just make invalid blocks the network rejects
10:17 < virtu> yeah, the LukeCoin network...
10:17 < luke-jr> belcher: no different than violating any other rule
10:17 < belcher> luke-jr right so thats a chain split :)
10:17 < luke-jr> virtu: if I were the only one, yes
10:17 < michaelfolkson> virtu: Please stay civil, that doesn't help
10:17 < luke-jr> belcher: that's a miner-created chain split
10:17 < virtu> what about nodes running LOT=false, they'd split, too
10:17 < luke-jr> virtu: which is why LOT=false has a risk
10:18 < belcher> luke-jr right, so LOT=true does in fact have a risk of chain split
10:18 < luke-jr> belcher: no
10:18 < luke-jr> belcher: that chain split is miners violating the rules, not LOT=true
10:18 < luke-jr> it's the same as if miners decided they want 50 BTC per block
10:18 < belcher> its a chain split where you strongly agree with one side
10:19 < belcher> 100% of the network checks the supply schedule, in the taproot activation it might not be like that, just by apathy of people not updating
10:19 < luke-jr> if Taproot is deployed with LOT=true, everyone is enforcing it
10:19 < luke-jr> except light wallets, same as with the supply schedule
10:19 < belcher> no, only the users who update would
10:19 < virtu> which is like 1/6th of the network
10:20 < luke-jr> not updated = light wallet
10:20 < luke-jr> virtu: it needs to be a supermajority before signalling even begins
10:20 < belcher> virtu and more importantly, its very hard to measure because the network is designed with privacy, you could be running over tor or faking your user agent
10:20 < belcher> thats why we go with miner signalling, because its the one thing thats measurable without centralization
10:20 < luke-jr> belcher: tor-only nodes are discouraged, and faking UA requires code changes
10:20 < virtu> that's why hash power should be used to coordinate
10:22 < belcher> tor-only nodes are not discouraged, they are great for helping hide the fact that you're even using bitcoin, but thats another topic... if you dont like tor theres also the blockstream satellite which is receive-only and therefore has good privacy too
10:22 < TechMiX> virtu: coordination like what we had in segwit activation? no thanks
10:22 < luke-jr> belcher: even worse, since it's a trusted peer
10:22 < luke-jr> I sure hope nobody much is using satellite-only for their node
10:23 < michaelfolkson> Good as a backup option
10:23 < queip> luke-jr: I would, since blocks are too big and don't have enough network data cap
10:23 < luke-jr> good as a way to reduce internet bandwidth, but nothing else
10:23 < luke-jr> as a backup it creates an attack vector
10:24 < luke-jr> queip: by making it exclusive, you are vulnerable
10:24 < luke-jr> queip: it can safely reduce bandwidth so long as you have internet peers to fall back on, too
10:24 < queip> luke-jr: I know. probably would verify chain tip hash with other computer elsewhere that I trust
10:24 < queip> before accepting payment
10:26 < queip> is there some more od config where I actually download blocks just from satelite, but I keep asking other peers for headers and only if there is a fork between then then I download from such peer block to see if he's telling truth?
10:27 < queip> *some mode or config
10:27 < luke-jr> dunno, I never got one
10:27 < luke-jr> gotta away-from-irc for a bit to figure out how to deal with a malware situation that has arisen
10:32 < queip> luke-jr: your signing keys are safe?
10:32 < luke-jr> queip: should be
10:33 < luke-jr> TBD if my hot wallet is, but nothing is missing from it, so probably
10:33 < virtu> 19:20 < luke-jr> virtu: it needs to be a supermajority before signalling even begins
10:33  * queip futurama-fry.jpg "not sure if message from Luke or from bot command center" >_>
10:33 < luke-jr> XD
10:33 < virtu> were you refering to a supermajority of nodes enforcing LOT=true?
10:33 < luke-jr> it's a Chromium extension called The Great Suspender
10:34 < luke-jr> not sure if extensions can access files
10:40 < luke-jr> https://github.com/greatsuspender/thegreatsuspender/issues/1263
10:50 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
10:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
10:58 < hebasto> in `feature_pruning.py` "This test takes 30 mins or more (up to 2 hours)" seems a bit outdated :)
10:59 < luke-jr> hebasto: wrong channel
10:59 < hebasto> ^ sorry
11:35 < aj> luke-jr: any joy with the code pr rebase btw?
11:38 < luke-jr> aj:  yeah, it's in my repo
11:38 < luke-jr> I didn't review it all, but rebased and squashed stuff
11:41 < luke-jr> [19:35:57] <michaelfolkson> Community consensus that a Core release will have false and this will be followed by another Core release in 6 months with true (if needed)
11:42 < luke-jr> such a pointless idea
11:42 < luke-jr> the first release has no purpose there
11:42 < aj> oh didn't realise the PR was updated. and CI is failing :(
11:42 < luke-jr> yeah, didn't investigate that yet either
11:43 < michaelfolkson> Assuming we don't want users to have to make that decision in the software that was the halfway house
11:44 < michaelfolkson> If halfway house isn't an option, it is a direct choice between true and false
11:44 < michaelfolkson> Which makes things simpler imo
11:55 < michaelfolkson> Ok I think the plan is then we have another meeting on February 16th and we try to get clear consensus for LOT = true. If there isn't clear consensus on LOT = true then we have to go LOT = false.
12:10 < luke-jr> why?
12:10 < luke-jr> LOT=false doesn't have clear consensus either
12:10 < luke-jr> LOT=true is status quo and less dangerous/risky
12:10 < luke-jr> regardless, code review should be the next meeting
12:15 < michaelfolkson> We are doing a Core PR review club for the code when it is ready?
12:18 < michaelfolkson> As soon as you think it is ready let me know and I'll try to get one organized with John
12:23 < michaelfolkson> One more meeting on LOT = true/false (primarily plus other parameters), a Bitcoin Core PR review club on the code and at an individual level that is all I can do. I'll leave it to you from that point on
12:26 < luke-jr> michaelfolkson: I don't mean to be a jerk, that was a serious question :P
12:26 < luke-jr> why would the default be LOT=false?
12:26 < aj> luke-jr: rpc_blockchain.py fixes are: testdummy startheight 0 -> 144; taproot: startheight, timeoutheight both -> 0, lockinontimeout -> True
12:28 -!- rdymac [uid31665@gateway/web/irccloud.com/x-hxnjgopssqfvddxv] has joined ##taproot-activation
12:37 < michaelfolkson> luke-jr: Not a jerk at all. I just want to put a limit on my involvement. I wasn't involved in 2017, don't have prior experience on these activations like you, I think doing these two things may be helpful but after that I don't think anything else is productive for me
13:03 -!- setpill [~setpill@unaffiliated/setpill] has joined ##taproot-activation
13:16 < belcher> after discussing on reddit and slack, i came across a new argument for LOT=true which i find quite convincing, the argument is that if LOT was true and a chain split happened then the taproot chain doesn't have wipeout risk, so theres a really strong incentive to be on the taproot-activating LOT=true chain, and therefore using LOT=true means the risk of a chain split is actually lower
13:16 < belcher> in case people weren't around in 2017 ill describe wipeout risk here:
13:16 < belcher> suppose LOT is true but only 30% of the miners signal, then after the final bip8 date taproot will activate and there will be a chain split, one side having 30% hashrate and having taproot, the other side with 70% hashrate and no taproot
13:16 < belcher> wipeout risk is that if the taproot chain gains more hashpower then it will wipe out the non-taproot chain in a blockchain reorg, but the reverse is not true, the non-taproot chain will never reorg out the taproot chain
13:17 < belcher> because the situation of having a big blockchain reorg is so awful for miners they will have a strong incentive to mine on the taproot chain, because thats how they protect themselves from a reorg, so we'll never actually end up in a situation where just 30% of hashpower mines the taproot-activated chain
13:17 < belcher> so coming back to LOT, i was initially concerned that LOT=true would mean a greater chance of a chain split, but because of wipeout risk it seems to be LOT=true makes a chain split less likely, not more likely
13:18 < aj> luke-jr: https://github.com/ajtowns/bitcoin/commits/202102-bip8-fixes has fixes for feature_taproot and rpc_blockchain; not seeing what's up with the fuzz failure
13:21 < aj> belcher: fwiw i don't find that very persuasive -- it's pretty trivial to prevent the wipeout once a chain split is established (just invalidate the first block of the chain you don't want to follow), and chain split tokens make it pretty easy to see in advance which will be more profitable to mine, so that chain will likely start off longer and then remain with more work anyway
13:23 < belcher> aj invalidating a block seems pretty hard to actually pull off, you as a miner have to convince all the exchanges and merchants to invalidate the same block, and anyone who wants to use that coin has to do invalidateblock as well
13:23 < belcher> but i guess exchanges might do it because they want more shitcoins to earn fees from?
13:23 < belcher> ok hmm
13:23 < aj> belcher: seems easy to pull off: explain to all the exchanges that all their transactions will be reversed if they don't run invalidateblock now, and apply this one line patch asap?
13:25 < belcher> however those exchanges cant trade with anyone else unless that customer also runs invalidateblock <blockhash> whenever they sync... its basically a new currency but where the user has to configure consensus parameters, a lot like BU
13:26 < belcher> so that coin will have to be worth much less, leading to it being much less profitable to mine and so lower hashrate
13:26 < belcher> bitcoin core and all the SPV wallets always follow the most-work valid (from their point of view) chain after all, so they'll always go with the taproot-activated chain eventually
13:31 < aj> belcher: for a non-taproot chain to be followed by anyone, you either have to start out deciding to be a minority fork, in which case you'll end up with a hard fork to make it cheaper like BCH; or it'll start off more valuable with a longer chain because the economic majority's not doing UASF
13:32 < aj> belcher: if the UASF chain continues (despite being pretty expensive compared to mining the main chain), people will treat it as two chains and add code to make sure they don't reorg back to the other
13:33 < belcher> the point about it being expensive will correct itself after one difficulty retarget
13:33 < aj> but all that's reason not to start trying to do an activation until we're sure there's community consensus that it's the right thing to do, and if we are sure of that, then to some extent UASF is a no-brainer anyway
13:34 < aj> it's expensive getting to that difficulty retarget
13:36 < aj> the two chains combined have to mine 2*2016*6.25 bitcoin worth of PoW (as determined by the previous difficulty) but the payout is only 1*2016*6.25*(1-chain1-coin + 1-chain2-coin) ; so if the sum of both coins is about the value of the single old coin, that's 2016*6.25 BTC wasted, or about $378M USD at $30k/BTC
13:37 < belcher> hmm, and this risk doesnt really exist if LOT=false, right?
13:39 < aj> if majority of miners activate, timeout doesn't get reached, so it doesn't matter?
13:39 < aj> not sure what you're asking
13:39 < belcher> LOT=true adds the risk of a chain split which happens if less than 50% of miners signal and enforce taproot
13:42 < aj> if some people collectively are willing to lose ~$380M they can get a chain split anytime, even without a soft-fork. if they're not willing to lose about that much, they can only do a hardfork, which is well-trodden ground at this point
13:45 < aj> that figure's well within scope for a state-based attacker, of course
13:45 < aj> state-level? whatever it's called
13:47 -!- Saxtheowl [~Saxtheowl@37.172.94.250] has joined ##taproot-activation
14:03 -!- Saxtheowl [~Saxtheowl@37.172.94.250] has quit [Ping timeout: 240 seconds]
14:10 -!- Saxtheowl [~Saxtheowl@37.169.39.189] has joined ##taproot-activation
14:26 < CubicEarth> aj: always important to keep the larger security picture in focus!
14:27 -!- Saxtheow1 [~Saxtheowl@37.169.41.242] has joined ##taproot-activation
14:30 -!- Saxtheowl [~Saxtheowl@37.169.39.189] has quit [Ping timeout: 246 seconds]
14:48 < setpill> an invalidateblock-based anti-uasf is very unlikely
14:49 < setpill> much more likely to have something like a mandatory non-signal softfork
14:50 < setpill> at least that can be prepared in advance, tested, etc
14:53 < setpill> much easier to coordinate in advance than ad-hoc
15:03 < belcher> yes any anti-uasf action would be for someone to do their own counter-uasf
15:04 -!- Saxtheowl [~Saxtheowl@37.169.27.168] has joined ##taproot-activation
15:07 -!- Saxtheow1 [~Saxtheowl@37.169.41.242] has quit [Ping timeout: 276 seconds]
15:08 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
15:45 -!- Saxtheowl [~Saxtheowl@37.169.27.168] has quit [Quit: Lost terminal]
15:54 < Aaronvan_> comment from gmaxwell: https://old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_will_be_able_to_veto/gm1tsrj/
15:54 -!- Aaronvan_ is now known as AaronvanW
16:16 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
16:23 -!- commmon [~common@unaffiliated/common] has quit [Read error: Connection reset by peer]
16:39 -!- queip [~queip@unaffiliated/rezurus] has quit [Remote host closed the connection]
16:40 -!- sword_smith [sword_smit@bitcoinfundamentals.org] has quit [Ping timeout: 240 seconds]
16:41 -!- sword_smith [sword_smit@bitcoinfundamentals.org] has joined ##taproot-activation
16:41 -!- queip [~queip@unaffiliated/rezurus] has joined ##taproot-activation
17:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
17:13 -!- TechMiX [~techtux@2001:4649:61c8:0:6076:8428:1ecd:be09] has left ##taproot-activation []
17:14 -!- TechMiX [~techtux@2001:4649:61c8:0:6076:8428:1ecd:be09] has joined ##taproot-activation
17:14 -!- TechMiX [~techtux@2001:4649:61c8:0:6076:8428:1ecd:be09] has left ##taproot-activation []
17:57 -!- CARO1 [~Cesar@2804:7f4:c19b:8c80:f1e9:6184:953b:115d] has joined ##taproot-activation
17:58 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
18:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
18:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
18:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
20:26 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
20:26 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
20:30 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
20:31 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
20:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
21:20 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
21:20 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
21:20 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
21:21 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
21:25 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
21:26 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
21:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
21:30 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
21:31 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
21:35 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
21:36 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
21:40 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
21:43 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
21:47 -!- rdymac [uid31665@gateway/web/irccloud.com/x-hxnjgopssqfvddxv] has quit [Quit: Connection closed for inactivity]
22:26 -!- pinheadm_ [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
22:28 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds]
23:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
23:50 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
23:50 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
23:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
23:57 -!- Belieffresh [~belieffre@titan.pathogen.is] has joined ##taproot-activation
--- Log closed Fri Feb 05 00:00:36 2021