--- Log opened Mon Jul 13 00:00:17 2020
01:44 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
03:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:53 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
03:56 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
05:00 -!- fanquake [sid369002@gateway/web/irccloud.com/x-olctokxewerkqszl] has joined ##taproot-activation
05:04 -!- rdymac [uid31665@gateway/web/irccloud.com/x-mtgojwnzssoqnbvb] has joined ##taproot-activation
05:07 -!- michaelfolkson [~michaelfo@2a03:b0c0:1:e0::23d:d001] has joined ##taproot-activation
05:08 -!- Ravi [6ad5a2b2@106.213.162.178] has joined ##taproot-activation
05:09 -!- Ravi [6ad5a2b2@106.213.162.178] has quit [Remote host closed the connection]
05:19 < michaelfolkson> What is the latest state of the activation discussion? There were the Matt/AJ mailing list posts on "Modern Soft Fork Activation" https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html
05:19 < michaelfolkson> And Luke has updated BIP8 https://bitcoinhackers.org/@lukedashjr/104403031242614180
05:20 < michaelfolkson> Anything else that we should be aware of?
05:21 < michaelfolkson> I am assuming that a proposed activation method should be formalized prior to the community outreach. Or should we have community outreach on what the activation method should be?
05:23 < michaelfolkson> Haven't yet looked at the logs I have missed http://gnusha.org/taproot-activation/2020-07-12.log
05:26 < michaelfolkson> Can you put a link to the conversation log in the channel topic please moneyball? (Luke, Will suggestion)
05:27 -!- _0x0ff [~potatoe_f@2001:bc8:47b0:123::1] has joined ##taproot-activation
05:36 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined ##taproot-activation
05:42 -!- cdecker [~cdecker@mail.snyke.net] has joined ##taproot-activation
06:08 -!- alec [~alec@gateway/tor-sasl/alec] has joined ##taproot-activation
06:27 -!- Netsplit *.net <-> *.split quits: meshcollider, pinheadmz
06:28 -!- Netsplit over, joins: pinheadmz, meshcollider
06:30 -!- BitcoinRunners [5af2ddc1@90.242.221.193] has joined ##taproot-activation
06:31 -!- BitcoinRunners [5af2ddc1@90.242.221.193] has quit [Remote host closed the connection]
07:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
07:39 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Ping timeout: 258 seconds]
07:40 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined ##taproot-activation
07:45 -!- roconnor [~roconnor@host-45-58-208-39.dyn.295.ca] has joined ##taproot-activation
07:57 -!- benthecarman [~benthecar@45.89.175.126] has joined ##taproot-activation
08:48 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-activation
08:57 -!- benthecarman [~benthecar@45.89.175.126] has quit [Remote host closed the connection]
08:58 -!- benthecarman [~benthecar@45.89.175.126] has joined ##taproot-activation
08:59 -!- thomasb06 [2ec100e0@gateway/web/cgi-irc/kiwiirc.com/ip.46.193.0.224] has joined ##taproot-activation
09:00 < thomasb06> Hello. What is taproot activation about?
09:04 -!- moneyball changed the topic of ##taproot-activation to: discussion about various activation proposals, community outreach, and general next steps to gain adoption. logs: http://gnusha.org/taproot-activation/
09:09 < instagibbs> thomasb06, discussion for if/how BIPs 340-342 should be activated on the Bitcoin network
09:13 < michaelfolkson> Thanks moneyball!
09:16 < thomasb06> Namely, activate a standard for 64-byte Schnorr signatures over the elliptic curve secp256k1, and activate a new SegWit version 1 output type, with spending rules based on Taproot, Schnorr signatures, and Merkle branches together with the semantics of its initial scripting system?
09:19 -!- real_or_random [~real_or_r@173.249.7.254] has joined ##taproot-activation
09:21 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
09:26 -!- thomasb06 [2ec100e0@gateway/web/cgi-irc/kiwiirc.com/ip.46.193.0.224] has quit [Quit: Ping timeout (120 seconds)]
09:26 < instagibbs> sounds right, but I'd just read those bips to get the totality of it
09:29 -!- thomasb06 [2ec100e0@gateway/web/cgi-irc/kiwiirc.com/ip.46.193.0.224] has joined ##taproot-activation
09:32 -!- achow101 [~achow101@unaffiliated/achow101] has joined ##taproot-activation
09:37 -!- thomasb06 [2ec100e0@gateway/web/cgi-irc/kiwiirc.com/ip.46.193.0.224] has quit [Ping timeout: 246 seconds]
09:40 -!- jeremyrubin [~jr@2601:645:c200:f539:6825:208:c554:712b] has joined ##taproot-activation
09:40 -!- thomasb06 [2ec100e0@gateway/web/cgi-irc/kiwiirc.com/ip.46.193.0.224] has joined ##taproot-activation
09:41 < pinheadmz> What are the arguments using BIP9 again? I don't believe taproot is nearly as controversial as segwit, although it would reduce miner fees (but allow more Txs per block, eventually)
09:42 < pinheadmz> *arguments against
09:42 < michaelfolkson> This is the part of the BIP which is relevant to this channel. https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#deployment
09:43 < michaelfolkson> There is ##taproot-bip-review channel for discussion about the rest of the BIPs
09:43 < thomasb06> instagibbs (some days my connection goes up and down... Thanks)
09:43 -!- harding [quassel@2600:3c03::f03c:91ff:fe7b:78d1] has joined ##taproot-activation
09:44 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
09:44 < jeremyrubin> I am curious what the motive is for not having discussion in the extant channel?
09:45 < pinheadmz> jeremyrubin i got a vibe that sipa wanted to be explicitly not involved in activation
09:45 < jeremyrubin> Ah that makes sense then, so he can not join this channel at his preference
09:46 < michaelfolkson> Yeah others as well as sipa aren't interested in this activation discussion
09:47 < jeremyrubin> may I suggest cross referencing ##taproot-bip-review's channel here and vice versa just so that it's clear where different components of discussion belong?
09:47 < jeremyrubin> here --> in the topic
09:48 < jeremyrubin> e.g.  The channel topic is "discussion about various activation proposals, community outreach, and general next steps to gain adoption. logs: http://gnusha.org/taproot-activation/". Technical discussions about Taproot itself belong in ##taproot-bip-review.
09:48 < zmnscpxj__> pinheadmz: re: arguments against BIP9: Miners are not necessarily interested in Bitcoin tech, and might not actually check any technical discussions and evaluate whether Taproot is useful
09:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
09:49 < zmnscpxj__> pinheadmz: this may lead them to ignore new features and not bother signaling them
09:50 < zmnscpxj__> pinheadmz: But BIP9 requires >95% signaling, so if even slightly more than 5% miners are apathetic, activation fails even if the more interested parties want it
09:50 < jeremyrubin> zmnscpxj__: slightly wrong
09:50 < jeremyrubin> 95% threshold implies like 80-85% IIRC
09:50 < jeremyrubin> Because there are time/signaling period rolls of the die
09:50 < zmnscpxj__> how so?
09:51 < jeremyrubin> so there's not a 1:1 mapping of % miners to % blocks mined
09:51 < michaelfolkson> Yeah makes sense. I have already asked moneyball to change it once so hopefully this will be last change to topic
09:52 < pinheadmz> Does 95% of the hashrate update bitcoind regularly when new versions are released?
09:52 < jeremyrubin> I also somewhat thing that there are two conversations here which are separately "Discussion of activation methods" and "Discussion of taproot activation"
09:52 < zmnscpxj__> my understanding is that no, updates are not necessarily immediate
09:52 < zmnscpxj__> though you have to ask people who are nearer to miners, not me, sorry
09:52 < jeremyrubin> It's maybe an interesting dichotomy because if certain folks aren't interested in the specifics for Taproot, they may be interested in the general activation mechanisms 
09:53 < michaelfolkson> What is the latter referring to jeremyrubin? Whether Taproot should be activated?
09:53 < ja> "segregated drama" :O
09:53 < zmnscpxj__> oh no
09:53 < michaelfolkson> Surely that is for ##taproot-bip-review for concerns
09:53 < jeremyrubin> michaelfolkson: not nesc whether directly, but the how
09:53 < zmnscpxj__> I think "exact methods for *this specific feature*" vs "general methods we want to use in the future"?
09:54 < pinheadmz> i think there is only a dichotomy if taproot could somhow be used to actually incentive miners to update
09:54 < pinheadmz> havent thought this through, but maybe a bunch of taproot TXs with extra miner rewards, etc
09:55 < jeremyrubin> Yes, like if it's a discussion of long term BIP-8 v.s. BIP-9 v.s. Modern SF Activation it's a broader community discussion than just taproot. But if it's just "what should taproot use in particular", then it is fine.
09:55 < pinheadmz> i suppose that wouldnt work though bc wintess v1 is anyonecanspend before acitvaiton anyway
09:55 < zmnscpxj__> in theory: taproot more useful -> Bitcoin more valuable -> more mining earnings per hash operation
09:55 < pinheadmz> zmnscpxj__ then bip9 should be fine :-)
09:55 < michaelfolkson> I was just assuming that "Modern soft fork activation" was applicable to all proposed future soft forks
09:55 < zmnscpxj__> Yes, theory meets the realworld, grumble grumble
09:56 < jeremyrubin> Sure, which makes discussion on adoption of mechanism relevant beyond just taproot.
09:56 < michaelfolkson> I would guess the only reason why people would really care about this topic is if it sets a precedent for future soft forks post Taproot (assuming Taproot is actually activated)
09:57 < zmnscpxj__> Every soft fork sets a precedent, IMO
09:57 < zmnscpxj__> "fight the last war"
09:57 < jeremyrubin> zmnscpxj__: and also every soft fork doesn't set any in a sense, as it's different every time
09:57 < jeremyrubin> zmnscpxj__: taproot is not segwit 
09:57 < michaelfolkson> SegWit activation is definitely informative to this discussion
09:58 < zmnscpxj__> Indeed, no softfork has ever been smooth
09:58 < zmnscpxj__> I think
09:58  * zmnscpxj__ looks around, wondering if somebody will point out a pre-SegWit softfork that went without a hitch
09:58 < jeremyrubin> That's not true
09:58 < jeremyrubin> Lots happened pretty smoothly, right?
09:58 < pinheadmz> zmnscpxj__ satoshi adding the 1MB limit ?!
09:58 < harding> zmnscpxj__: the Nakamoto soft forks, BIP30, and BIP68/112/1113 were smooth, I think.
09:58 < zmnscpxj__> okay, such as?
09:59 < zmnscpxj__> Ah
09:59 < zmnscpxj__> so when did softfork problems start?
09:59 < jeremyrubin> I think Taproot has more in common with those than segwit
09:59 < harding> zmnscpxj__: BIP16.
09:59 < pinheadmz> oh right there was an OPEVAL proposal right?
09:59 < jeremyrubin> even BIP16 deployment itself was relatively smooth though
09:59 < jeremyrubin> Just the "which thing" one wasnt
10:00 < michaelfolkson> Before my time but this is the timeline https://blog.bitmex.com/bitcoins-consensus-forks/
10:00 < pinheadmz> the community is different now. a lot of the users who opposed segwit just dont use BTC anymore
10:00 < pinheadmz> might be worthwhile to poll social communities in addition to develoeprs
10:00 < roconnor> Ultimately it is the (economic) nodes that enforce consensus rules.  Miners have pretty mixed motivations when it actually comes to enforcing rules, and have shown themselves to be somewhat unreliable at enforcing consensus rules.  Activation is largely about giving these economic nodes enough time to upgrade and, using the blockchain, to coordinate their simultaneous activation.
10:00 < roconnor> If enough miners are actively enforcing rules by censoring invalid transactions, they can be used to add safety to activation, but ultimately it is the (economic) nodes that matter.
10:00 < harding> BIP65 and BIP66 were also smooth, although BIP66 had the July 4th forks at the end.
10:01 < jeremyrubin> (even though I hate it, might make sense to open a telegram channel to discuss this. "If the mountain will not come to Mohammad, Mohammad must go to the mountain"
10:01 < harding> Why telegram?
10:01 < zmnscpxj__> roconnor: so an argument towards UASF?
10:01 < jeremyrubin> There's just a very different cross section of Bitcoin participants there.
10:02 < harding> jeremyrubin: that's fair, but I think we're still at the stage of formulating technical proposals.  If the technical community can't all get on board a particular proposal, then it's probably time to bring the multiple proposals to the larger community and ask them to decide.
10:03 < jeremyrubin> Some nym (rocket_fuel) made a channel for CTV there, and convinced me to participate, and I've been very pleased with the types of people who participate and the perspectives. Better mix of devs, users, miners, operators.
10:03 < roconnor> zmnscpxj__: Maybe you could say that.  I think BIP-9 with a timeout of activating instead of aborting (maybe this is what BIP8 is?) is appropriate.
10:04 < michaelfolkson> Feel free to set one up jeremyrubin. Doesn't have to be monopoly on discussion
10:04 < zmnscpxj__> My reading of the new BIP8 is that it is indeed so, with something very much like BIP9 as a sub-option depending on lockinteimout (false=BIP9, true=UASF)
10:05 < jeremyrubin> I'll ask rocket_fuel if he wants to set one up, running TG groups is not my forte. And if anyone wants to join the CTV TG group, just DM me and will send the link.
10:06 < zmnscpxj__> Would it be useful to see "what went right" and "what did not went right" softforks?
10:06 < benthecarman> So for the new bip 8, is the idea users can just enter an rpc command to set lockinontimeout to true if they want to uasf it
10:07 < michaelfolkson> I would say yes. I literally know nothing about how soft forks pre SegWit were activated
10:08 < harding> zmnscpxj__: I think all the lessons learned from early soft forks were bundled into BIP9 (e.g. BIP30 lead to BIP34 ISM soft forks; BIP66 ISM post-activation went into BIP9 signaling periods).  What's probably most relevant now is how BIP9 was unsatisfactory during segwit.
10:08 < harding> BIP30 flag day*
10:08 < zmnscpxj__> So is looking at SegWit, plus a summary of rationales for BIP9, sufficient?
10:08 < harding> benthecarman: I think it would be a bitcoin configuration option that you'd add to your bitcoin.conf, but basically.
10:09 < roconnor> Users are going to be uncoordinated if some are using lockinontimeout = true and some are lockinontimeout = false.  That strikes me as very bad.
10:09 < zmnscpxj__> benthecarman: uncertain, my reading of the text is that this is a parameter selected by developers, which could be (?) overridden by users, maybe
10:09 < zmnscpxj__> probably best to clarify with luke-jr
10:10 < harding> roconnor: no, the revised BIP8 has a mandatory signaling period, so if the lockin = true users are successful at forcing miners to signal, the lockin = false users will start enforcing the other soft fork rules at the same time.
10:11 < jeremyrubin> So I have a talk from a while ago. https://www.youtube.com/watch?v=J1CP7qbnpqA It's worth watching for the analysis part. I think that things like "Modern Soft Fork Activation" which introduce more time/latency and signaling period without honesty end up just taking more time. I'm not sure that the product of taking more time is a better outcome, though.
10:11 < harding> zmnscpxj__: I think that would be sufficient, but I already know about many previous soft forks so I'm might not be the best judge of what knowledge people need.
10:11 < zmnscpxj__> the BIP8 text lists lockinontimeout together with name, bit, startheight etc. which are params we do not expect users to override
10:11 < jeremyrubin> Transcript http://diyhpl.us/wiki/transcripts/stanford-blockchain-conference/2019/spork-probabilistic-bitcoin-soft-forks/
10:12 < jeremyrubin> I'm generally more favorable to single deployment BIP-8 for this reason.
10:12 < zmnscpxj__> jeremyrubin: so full UASF? not modern softfork activation?
10:12 < harding> Optech's summary of jeremyrubin's spork: https://bitcoinops.org/en/newsletters/2019/02/05/#probabilistic-bitcoin-soft-forks-sporks
10:13 < jeremyrubin> I think the issue is with Modern Softfork Activation is if you look at from a game theoretic perspective, you always end up going to the second timeout
10:13 < jeremyrubin> So the value of the first period is questionable IMO
10:13 < jeremyrubin> Miners have incentive to withhold to gain more influence/request favors
10:13 < harding> jeremyrubin: how is that game theoretic if >95% of hash rate wants the fork?
10:14 < harding> Ah.
10:14 < jeremyrubin> Even if you want it
10:14 < zmnscpxj__> ah
10:14 < jeremyrubin> you can fake saying "I don't want it"
10:14 < harding> (I don't believe that, but it's plausable.)
10:14 < zmnscpxj__> so taking the new feature hostage, something like that?
10:14 < jeremyrubin> And then say "here's what I need to see from {core, the community, etc}"
10:14 < jeremyrubin> And if you're the one hold out, then you're going to have more voice in the timeout period
10:15 < jeremyrubin> Exactly
10:15 < jeremyrubin> It may not happen for Taproot. But if it's in the mechanism, it will happen at some point
10:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
10:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
10:15 < jeremyrubin> Now I'm not saying spork is the answer, but it's at least a *type* of answer if you're trying to be concious of competing activation incentives
10:16 < jeremyrubin> But it's what biases me towards single period shorter activation cycles.
10:16 < zmnscpxj__> on the other hand, with BIP8 definitely-upgraded-at-timeout, miners might argue that developers are taking their hardware hostage, requiring upgrades etc
10:16 < jeremyrubin> I think you can make it so that there's no default arg
10:16 < jeremyrubin> Node won't start without a decision maybe?
10:16 < roconnor> zmnscpxj__: I somewhat wish we used a term like, Activate-On-Timeout or something instead of UASF, which seems to have become a politcally charged term (for no good reason).
10:16 < jeremyrubin> So users are really in control
10:17 < zmnscpxj__> BIP8?
10:17 < jeremyrubin> harding: thanks for the summary it's probably sufficient for people to just read that :)
10:17 < zmnscpxj__> jeremyrubin: some users might have set up some kind of automatic update
10:18 < michaelfolkson> So spork forces skin in the game if you oppose right? You forsake block reward if you oppose. But why not force any kind of signal? Positive or negative. The problem is there is no signal at all right?
10:19 < jeremyrubin> Well interestingly you forsake a block reward but it difficulty adjusts out over time
10:19 < jeremyrubin> And if it's e.g. 1 block in a year, then it is very low negative EV overall
10:19 < michaelfolkson> Or in other words indifference is more of a problem than opposition. Opposition (with explanation) should be encouraged
10:20 < jeremyrubin> michaelfolkson: I can understand that too. If you want people to express an opinion, tell them it's activating in 1 month better update now ;)
10:20 < zmnscpxj__> so in theory: spork ensures that indifference is counted as support?
10:20 < michaelfolkson> Yup that is my understanding
10:20 < jeremyrubin> I think that's what we want generally.
10:20 < zmnscpxj__> "silence means approval"
10:20 < jeremyrubin> Miners should be indifferent to what my txns are doing, it's not their business, right?
10:21 < jeremyrubin> And for a large scope of soft forks (maybe not all, segwit was big), if I want to do something, and a miner doesn't care for the feature, but isn't harmed, i should be able to
10:21 < michaelfolkson> I want to know if miners have opposition. I'd rather find that out than threaten them with economic loss if they oppose
10:22 < jeremyrubin> michaelfolkson: I think you're mixing indifference with having opposition but not voicing it
10:23 < zmnscpxj__> how can you make them voice their opposition unless you threaten economic loss?
10:23 < jeremyrubin> zmnscpxj__: I think fundamentally, and what we learned with segwit, is you can't
10:23 < harding> zmnscpxj__: miners are paid in Bitcoin and are forced to hold it (albeit only for 17 hours on average), so they have at least some stake in the system.
10:23 < michaelfolkson> I am saying why not threaten them with economic loss if they refuse to signal at all. Don't threaten them if they oppose
10:24 < jeremyrubin> harding: miners can mine into lightning channels though harding
10:24 < harding> (In practice, their stake is much longer---the duration their equipment is profitable to operate.)
10:24 < zmnscpxj__> I think the covert Asicboost was instructive: it was an opposition to SegWit that was unvoiced because of its covertness
10:24 < harding> jeremyrubin: ok, so they have to hold for one hour.  :-)
10:24 < jeremyrubin> maybe I should write a spec for that :)
10:25 < zmnscpxj__> jeremyrubin: does it not need a less than operation to be activated?
10:26 < jeremyrubin> zmnscpxj__: moved to #lightning-dev
10:27 < michaelfolkson> My understanding of Modern Soft Activation posts are it is in phases. First phase is ask miners initially with no gun to their head or otherwise threat of economic loss whether they support proposal. 
10:28 < ja> michaelfolkson: the bitmex timeline is missing the 2018 CVE, which is also a fork, depending on your definition
10:28 < michaelfolkson> You want to know either way yes or no whether they do support it or not. You want forced signaling, not forced acceptance in that first phase
10:30 < harding> michaelfolkson: I don't know what you mean by "forced signaling"?
10:30 < luke-jr> zmnscpxj__: miners and devs have no say/decision in protocol changes; it's up to the entire community
10:30 < harding> (in that context)
10:30  * jeremyrubin mild dyslexia really triggered with ja and aj
10:30 < michaelfolkson> My (limited) understanding is that some people think miners shouldn't be asked at all because they don't matter and some of them didn't cover themselves in glory with SegWit soft fork
10:31 < luke-jr> jeremyrubin: IMO BIP9 died with BIP148. Not only did it prove the game theory was broken, it also revealed problems with using MTP (which forced the UASF to be rushed)
10:31 < harding> michaelfolkson: miners qua miners should implement the policy decided on by the users, but miners are also often Bitcoin users and so they can act as rough proxies for the community.
10:31 < jeremyrubin> Yeah my point is not that people shouldn't have a say, it's that people have incentive to use any time offered to them.
10:32 < jeremyrubin> So if we're offering time, we should make sure that time is used well
10:32 < jeremyrubin> BIP-9 fails this test
10:32 < jeremyrubin> I think Modern SF fails too
10:32 < luke-jr> currently we have a precedent that is effectively BIP 8; it worked
10:32 < harding> I'm +1 on modern SF.  I think that time is wisely allocated to letting the whole community---not just the miners---make sure we're really ok with the fork.
10:32 < michaelfolkson> harding: Blocks included in the chain have to have a positive or negative signal to gauge whether there is miner support or not. Rather than just not signaling at all and their blocks being included in the chain
10:33 < luke-jr> harding: that needs to happen before ANY deployment
10:33 < luke-jr> of activation params*
10:33 < zmnscpxj__> harding: I think what michaelfolkson is referring to is the spork thing, where miners that do not signal for activation have to sacrifice value
10:33 < harding> michaelfolkson: not signaling is a fine negative signal.
10:33 < jeremyrubin> I agree strongly with luke-jr on that. 
10:33 < michaelfolkson> harding: That assumes indifference is opposition. Surely a weak assumption?
10:33 < zmnscpxj__> harding: but what michaelfolkson wants is a clear signal: signal true, signal false, if you do not signal either you have to sacrifice value
10:34 < jeremyrubin> signal true is building on a block that activates btw
10:34 < harding> luke-jr: that should indeed happen before deciding on the params, but developers can't know what the community wants for sure.  The real test is people actually running the code.
10:34 < jeremyrubin> signal false is orphaning those blocks
10:34 < luke-jr> roconnor: as for terminology, 1) saying UASF is political is like saying being against tyranny is political - maybe technically, but it's one we should expect and demand from everyone; 2) the term used in BIP 8 is "lockin on timeout"
10:34 < jeremyrubin> either way it's costly if you're not with majority
10:35 < luke-jr> harding: which is why the master Bitcoin Core releases shouldn't include activation, and people should be told to run a "Bitcoin Core Taproot" variant if they want it
10:35 < zmnscpxj__> luke-jr: interesting idea
10:35 < luke-jr> before BIP148, I would have questioned if it would work, but BIP148 proved it does, and so we should continue that precedent IMO
10:35 < harding> luke-jr: that's silly, like all of your ideas for Bitcoin Core not shipping with sane defaults.
10:36 < michaelfolkson> Should there be a deployment section in the BIP in your opinion luke-jr?
10:37 < jeremyrubin> harding: I don't think *all* of luke-jr's ideas are silly. But a good amount of them are. Saying that activating or not is a sane default is implying users who want something else are insane.
10:37 -!- ksedgwic [~ksedgwic@157-131-108-129.fiber.dynamic.sonic.net] has joined ##taproot-activation
10:37 < luke-jr> harding: Bitcoin Core *doesn't* ship with sane default..
10:37 < luke-jr> michaelfolkson: yes
10:38 -!- harding [quassel@2600:3c03::f03c:91ff:fe7b:78d1] has left ##taproot-activation ["http://quassel-irc.org - Chat comfortably. Anywhere."]
10:38 < ja> why not put deployment in a separate BIP given that it is less clear how to do it right, and it depends on social constructs?
10:38 < jeremyrubin> luke-jr: Core includes ability to flag-in a yes/no, Taproot = default yes?
10:38 < luke-jr> ja: well, BIP 8 is a separate BIP; but parameters are simple enough they should be in the specific BIP for the proposal
10:39 < zmnscpxj__> ja: one can argue that BIP8 is that BIP
10:39 < jeremyrubin> Seems reasonable to ship two different builds for that, if not a bit annoying procedurally.
10:39 < luke-jr> jeremyrubin: what?
10:39 < jeremyrubin> I'm saying there are two versions you can run, one which allows you to change yes/no on activation logic, one where it's just fixed yes
10:40 < jeremyrubin> In your model of "the user decides what to run"
10:40 < zmnscpxj__> ...... or just two different software, one "yes" the other "no"? maybe simpler?
10:40 < zmnscpxj__> could do the optionality as a preprocessor flag you set on configure script
10:41 < luke-jr> jeremyrubin: ideally, upgrading would give a nice prompt to the user explaining the change in the GUI etc, but that effectively turns devs into gatekeepers
10:42 < zmnscpxj__> luke-jr: the dev can give a lousy explanation that turns off people on the change, sort of thing?
10:42 < luke-jr> zmnscpxj__: or refuse to deploy it entirely
10:42 < luke-jr> like with BIP148
10:42 < luke-jr> Core rejected even having a config option
10:42 < luke-jr> which forced the issue of a separate build to install/use
10:43 < zmnscpxj__> well, you can always fork, which is what happened with BIP148 in the end right?
10:43 < luke-jr> best to just make it the norm so the issue is avoided
10:43 < zmnscpxj__> "the ultimate open-source nuke: 'f**k you!'"
10:43 < jeremyrubin> I think it's really a question for users maybe?
10:43 < luke-jr> kinda similar to the incentive problems with MASF actually
10:44 < luke-jr> giving miners control, they abuse it
10:44 < jeremyrubin> Good place to involve a TG group -- how do you want to choose for upgrades?
10:44 < roconnor> Agree with harding.  When it comes to conensus rules, it is important to put everyone on the same page and avoid handing users a bunch of options that will shoot themselves in the foot.  Developers should simply create the best software that they can and if for whatever reasons users end up rejecting those changes, they are free to write their own software.
10:44 < luke-jr> giving devs control, they're also incentivised to abuse it
10:44 < zmnscpxj__> give anyone control, they abuse it
10:45 < luke-jr> (as for the topic of lockinontimeout being user-configurable, that's IMO a separate discussion)
10:45 < luke-jr> jeremyrubin: TG group?
10:45 < mblackmblack> agree with jeremyrubin. A simple TG group poll would give some color on this
10:45 < zmnscpxj__> which seems to suggest that ultimately, devs are limited by the threat of "fork you"
10:45 < roconnor> Devs don't have control.  That control was given up when Bitcoin code was given an MIT license.
10:46 < luke-jr> zmnscpxj__: Core development processes have made forks impractical
10:46 < michaelfolkson> Feel free to set up a Telegram group and come back with thoughts/opinions. I don't know why this is being brought up. No one is saying you can't set up a Telegram group...
10:46 < zmnscpxj__> BIP148 seemed to work out well enough
10:47 < luke-jr> zmnscpxj__: ah, I just see that as an activation release of the same project
10:47 < jeremyrubin> michaelfolkson: this is a group with people who are trying to figure out among this group what's the right ways to engage with the community and participants. I'm making a suggestion, not a threat, and asking what people think about it :)
10:47 < jeremyrubin> So just saying "do whatever you want" doesn't really answer the question, which is, is a group like that viewed positively by this group?
10:47 < luke-jr> jeremyrubin: while perhaps part of the community uses Telegram, it isn't any more or less special than any other subset ;)
10:48 < jeremyrubin> luke-jr: just non-overlapping IRC
10:48 < luke-jr> I'm more inclined to discourage using Telegram for anything
10:48 < luke-jr> it's easy for people to join IRC to discuss this; but it's a nuisance to join Telegram
10:49 < michaelfolkson> I am happy to join a Telegram group to see if anything comes of it. But I'm not particularly interested in talking about setting up a Telegram group repeatedly
10:49 < zmnscpxj__> luke-jr: I would think it depends on what software you ordinarily use otherwise
10:49 < jeremyrubin> Now that's an idea I'll call you silly on ;)
10:49 < luke-jr> zmnscpxj__: it's easy to use IRC software, there's even web access
10:50 < luke-jr> for Telegram, you effectively need to compromise your computer's security
10:50 < ja> luke-jr: given that IRC doesn't have history per default, people have to know that they can use IrcCloud or the like. how is that 'easier'? i am not saying i don't prefer IRC, but to call it easier is ridiculous
10:50 < ja> most people will happily 'compromise' their security by your standards
10:50 < luke-jr> something that should be discouraged, especially in the context of Bitcoin ;)
10:51 < michaelfolkson> Ok coming back when topic is on pros and cons of activation methods rather than IRC vs Telegram :)
10:51 < zmnscpxj__> right, right, I would like to point out that Telegram or not is not arguably off-topic and maybe we can set up some bridge somewhere and link to it or something
10:51 < jeremyrubin> lest anyone think this is irrelevant, knowing what forums you're actually likely to get feedback is really important
10:51 < zmnscpxj__> great, too many "nots"
10:51 < jeremyrubin> indifference, consent, dissent, "didn't know I was being asked"
10:52 < jeremyrubin> just IRC + mailing list is quasi equivalent to the silent assumed-yes 
10:52 < zmnscpxj__> can a bridge be built between this channel and a TG group? Like the lndbot bridge between #lightning-dev and the lnd slack
10:53 < jeremyrubin> Maybe? might be a pain. rocket_fuel made a group so will share the link
10:53 < zmnscpxj__> would it be good to put in the topic? @moneyball?
10:54 < luke-jr> ?
10:55 < zmnscpxj__> anyway I have to afk for now, hope something useful gets discussed soon
10:55 < jeremyrubin> https://t.me/bips_activation
12:05 -!- schmidty [sid297174@gateway/web/irccloud.com/x-ckqifnzpczeptffn] has joined ##taproot-activation
12:11 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-activation
12:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-activation
12:35 < michaelfolkson> One suggestion in the Telegram is to work towards an equivalent of this for Taproot activation methods. Any thoughts? What were people's views on this at the time of SegWit? https://en.bitcoin.it/wiki/Segwit_support
12:36 < benthecarman> I think that's a good idea
12:36 < michaelfolkson> Who put this together and contacted all the developers and businesses at the time? A lot of work but perhaps unavoidable?
12:37 < michaelfolkson> It needs concrete proposals though. Matt's mailing list post seems pretty concrete and Luke's BIP is getting there. I don't know if there will be other proposals with support
12:48 -!- zfrohardt [49539482@c-73-83-148-130.hsd1.wa.comcast.net] has joined ##taproot-activation
12:50 -!- pigeons [~pigeons@androzani.sysevolve.com] has joined ##taproot-activation
12:55 < schmidty> Ive done some outreach regarding taproot support. Happy to drive something like the Segwit_support page for taproot if folks see it as valuable.
13:00 < alec> given that softforks before segwit went down fine, maybe a discussion on how much of taproot's activation should integrate "lessons learned" from segwit is in order. maybe too much "premature optimization" will negatively impact or unnecessarily complicate things
13:02 < michaelfolkson> bitschmidty: Cool. I definitely think it would be a good resource to point people to even if there ends up being broad clear consensus
13:02 < michaelfolkson> schmidty*
13:04 < michaelfolkson> alec: It is not clear they all went down fine (see earlier discussion). Not as fraught as SegWit maybe. Lessons to be learned from all of them
13:04 < michaelfolkson> What particular "premature optimization" are you concerned about?
13:06 < alec> michaelfolkson: right, I should have added a 'mostly'
13:06 < michaelfolkson> Worst case scenario is that any soft fork post Taproot (assuming we get Taproot) has different activation method to Taproot (but ideally it would be informed by how the Taproot activation went)
13:08 < alec> michaelfolkson: something like addressing too many issues that were encountered during segwit activation
13:10 < michaelfolkson> There are kind of two opposite dangers that I see. One that we "fight the last battle" when Taproot activation is a very different challenge to SegWit (hopefully will be much less fraught)
13:11 < gmaxwell> I continue to be of the view that trying to hard to plan everything out is a waste of time. It's best to assume things will go well and adapt if they don't. Planning is mostly useful to the extent that it keeps options open.  Making too big a deal about this stuff invites the negative outcomes.  I think there are real problems with bip9, sure, but the best way to make it clear how to address 
13:11 < gmaxwell> them is by exposing them through more softforks.  I'm pretty disappointed that the cleanup consensus changes (e.g. fixing several outright vulnerablities, though more minor ones) hasn't yet moved forward.
13:12 < michaelfolkson> You mean Matt's Great Consensus Cleanup soft fork?
13:13 < michaelfolkson> Or cleanups generally?
13:13 < gmaxwell> Yes. What I'd urged him to do was strip any parts that were seriously umbigious, e.g. roconnor found issues with the codesep fix... and keep it moving forward.
13:14 < alec> gmaxwell: that's a pragmatic approach people can get behind
13:15 < michaelfolkson> Perhaps it needs a new "champion". I'm assuming rust-lightning keeps Matt pretty busy
13:15 < michaelfolkson> I did wonder what had happened to that. Hasn't been discussed much recently
13:15 < michaelfolkson> (that I've seen)
13:16 < gmaxwell> People are rightfully concerned that whatever future consensus changes happen will be politized to disrupt bitcoin.  It concerns me too. However, the only way to deal with that is to just move forward.  Stuff like cleanups would have helped build confidence that consensus changes can happen without being a big mess.
13:16 < gmaxwell> michaelfolkson: My read on it is that the people most qualified to pull stuff like that forward are fed up with bullshit and easily discouraged, and other people who are less easily discouraged don't have the confidence/expirence needed to drive consensus changes forward.
13:18 < jeremyrubin> gmaxwell: what do you think about breaking matt's consensus cleanup into independent soft forks? 
13:18 < michaelfolkson> There are a lot of competing proposals. Perhaps he just thought it wasn't likely to get in before Taproot?
13:19 < jeremyrubin> I think one of the things it suffered from was cramming too many independent changes into one activation (which was bad since roconnor's codesep points sunk the others)
13:19 < gmaxwell> Part of the motivation for moving forward with it at the time was to build confidence that more substantive changes could be done, so ::shrugs::
13:20 < gmaxwell> Before he published it, he has agreed with my argument that if any part of it turned out to have real issues, just to drop that part.  Many of the changes there really aren't substantive enough to carry on their own in any case...
13:21 < gmaxwell> I feel like I'm getting a bit offtopic, -- I just think it's a fine example that there is a lack of sufficient energy to overcome conjectured political drama... drama that might be 99% imagined (not because taproot is fundimentally different, I don't agree with that, but because the climate is not the same)
13:21 < gmaxwell> Plus no plan survives contact with the enemy.
13:22 < michaelfolkson> But regardless this activation conversation would still have to have been had right? Whatever the nature of the soft fork. I have seen very little opposition to Taproot thus far so perhaps it performs role of a soft fork with very little drama
13:22 < gmaxwell> michaelfolkson: sure, I guess my point though is that picking something that isn't too weird or objectionable, and going forward with it is better than debating what-ifs forever.
13:23 < jeremyrubin> gmaxwell: re: [7/13/20 13:18] <michaelfolkson> There are a lot of competing proposals. Perhaps he just thought it wasn't likely to get in before Taproot?
13:23 < gmaxwell> If an activation doesn't work out, it can just be tried another way.  I earnestly believe that if it weren't for activation-drag taproot would be activated already. (the drag has also slowed development)
13:23 < jeremyrubin> Do you think that soft fork work inherently is serial?
13:23 < jeremyrubin> Does someone picking up consensus cleanup detract from Taproot timeline?
13:25 < gmaxwell> I think they're somewhat serial.  There are only so many resources to go around reviewing, comprehending, commenting on, debating, and managing changes. Though it also depends on the character of the changes.  Like can some extremely narrow, zero-effect-in-practice timestamp handling fix run in parallel to taproot?  very likely.  Can two massive script reworkings?  less likely.
13:27 < michaelfolkson> Hopefully Matt, Luke proposals will converge and there will be one that has broad consensus. The challenge that is presented is who picks if there are alternative competing activation methods
13:27 < michaelfolkson> I would certainly be happy with that as I think many others would ;)
13:28 < gmaxwell> Well I hope everyone contributing to the discussion adopts my perspective that there isn't a lot of gain in choosing the "best",  it's just important to choose something okay and learn from it.
13:28 < gmaxwell> I have zero doubt that the community can spend another whole year debating activation methods ... a time during which actual activation with $whatever could have just happened, with high probablity.
13:28 < jeremyrubin> gmaxwell: do you think that 'hindsight 2020' we'd be better if we had done Mast and then Schnorr and then Taproot? Where you add marginal value along the way?
13:29 < jeremyrubin> in line with small things to learn from
13:29 < gmaxwell> The downside of a failed activation of a good feature that people want is just delay. Delay sucks.  But delaying to debate how to activate it to reduce delay is no less delay.
13:30 < gmaxwell> jeremyrubin: No, I don't think those proposals are all that isolatable, and the seperation creates technical debt, loss of fungibility, etc.  Already taproot itself was a compromised cut down proposal from something that could do signature aggregation and graftroot.
13:31 < gmaxwell> but like, breaking up the cleanup fixes?  It seems still to me to do so, but it wouldn't have been crazy to.
13:31 < gmaxwell> s/still/silly/
13:32 < gmaxwell> (Rather there, I would have favored stripping out any parts that weren't totally clear and handling them seperately)
13:32 < luke-jr> gmaxwell: BIP9's existing known issues are all addressed in BIP 8 though, and as a bonus this is an ideal time to switch over becasue the BIP 9 code is unused
13:32 < gmaxwell> the distinction there is that stuff like the consensus cleanup has little to no downstream software interaction,  you don't end up with a big legacy of user scriptpubkeys using the old stuff, etc.
13:32 < gmaxwell> luke-jr: sounds fine to me, assuming other people are cool with it.
13:33 < jeremyrubin> gmaxwell: I think your point applies nicely to activation methods
13:33 < gmaxwell> I'm not saying don't do bip8. I'm saying that I think the difference between the myriad variations are of less concern than the effect of just delaying more and not learning.
13:33 < jeremyrubin> I think it's pretty reasonable to see what goes wrong with BIP8
13:34 < jeremyrubin> rather than anticipate what goes wrong (with Modern SF)
13:34 < jeremyrubin> I think that Taproot could enjoy a pretty expedient activation
13:34 < jeremyrubin> I don't think there's anything deeply conceptually wrong with Taproot or Bip9
13:34 < jeremyrubin> *bip8
13:35 < luke-jr> I mean, BIP 8 isn't final either if someone has concrete improvements; but yeah, we can always do a BIP 7 or whatever for post-Taproot if new issues arise later
13:35 < gmaxwell> The modern SF stuff encapsulated a bit of game theory (e.g. making it unambigious that uncooperative hashrate can delay but not block something users want)-- but that game theory might be unnecessary:  I think the bigger issue isn't blocking, the bigger issue is apathy.  And the only approaches I know that address apathy do it via introducing instaibility (e.g. invalid blocks) and so they'll 
13:35 < gmaxwell> be controversial.
13:36 < jeremyrubin> I think the game theory also pointed to using as much delay as possible, but not everyone agrees with that (see earlier discussion here)
13:36 < michaelfolkson> This is certainly framing it in a different way to how I was initially thinking. This ditches the "let's make this a precedent" framing that I had in my head. It is convincing though. I am certainly more concerned with apathy than SegWit style controversy this time
13:36 < gmaxwell> jeremyrubin: I think it would be extremely easy to argue against taproot using exactly the same form and structure of false arguments ("disrupts the chain of digital signatures!") used against segwit.   But ... so what?  If it happens it happems getting caught up in an endless debate about activation methods doesn't fix it.
13:37 < gmaxwell> hah. I think precident is only a concern to the extent that you never want to set a bad one.  E.g. don't take actions that you'll be ashamed of in the future.
13:37 < roconnor> bip8 with lockinontimeout configured to true seems like a fine activation method.
13:37 < luke-jr> gmaxwell: mandatory signalling might be sufficient?
13:38 < jeremyrubin> What about reverse BIP8 out of curiosity? 
13:38 < luke-jr> jeremyrubin: elaborate?
13:38 < jeremyrubin> activates on timeout unless 95% reject?
13:38 < gmaxwell> luke-jr: to fix apathy?  I think it would be, but I think it would be controversial. (I'm not even sure I'd wouldn't argue against it... unsure partly because I don't really know how bad apathy is right now)
13:38 < luke-jr> jeremyrubin: miners don't decide, only optimise
13:39 < gmaxwell> luke-jr: it flips apathy in the right direction at least.
13:39 < luke-jr> gmaxwell: _not_ doing mandatory signalling would be controversial
13:39 < gmaxwell> luke-jr: I mean anything that causes apathy to create network instability is, in my view, not obviously the right choice.
13:40 < gmaxwell> But I don't know how to address apathy otherwise.
13:40 < jeremyrubin> Concretely you could have a 95% optimize action bit, and a 95% emergency abort activation bit which turns on halfway through the signaling window.
13:41 < luke-jr> jeremyrubin: if we need an emergency abort, I think giving it to miners is a bad idea
13:41 < jeremyrubin> Would at least be smoother than "we discovered a problem, restart your node with a new argument". 
13:41 < jeremyrubin> luke-jr: but miners can just choose to not mine any taproot outputs
13:42 < jeremyrubin> which is also kinda worse
13:42 < roconnor> It's probably best to deal with discovered problems the same way we deal with all other discoved problems in Bitcoin.
13:42 < luke-jr> jeremyrubin: 20-of-20 flood network message would work better
13:42 < luke-jr> jeremyrubin: miners can't decide to take taproot UTXOs though
13:42 < gmaxwell> To be clear to bystanders why I think we're talking about with apathy: It's my expirence that mining pools are often extremely slow at applying upgrades, for business justified reasons (they take a risk on upgrades, and they're busy with trashfire altcoins)... many miners themselves aren't deeply involved in the ecosystem (e.g. I've met a number of very big ones that mine directly to an 
13:42 < jeremyrubin> they can because of segwit version :(
13:42 < gmaxwell> exchange account and have never used a bitcoin wallet),  it's unlikely that in the short to mid term taproot is going to improve the income of miners... and the way BIP9 works, there is no reason to bother applying the upgrade until the lock-in period starts. So thats a bit of a catch22.
13:42 < luke-jr> jeremyrubin: not once it activates
13:43 < jeremyrubin> ah take you mean steal
13:43 < jeremyrubin> I'm talking about confirm
13:43 < jeremyrubin> They can burn by allowing spend to but not spend from ;)
13:44 < luke-jr> until someone else mines it
13:44 < gmaxwell> If I could wind back the clock to 2011 I would have proposed different activation mechenisms that made it more clear that for things like script improvements people aren't asking miners specifically for their permission.
13:44 < jeremyrubin> that's why you set a high abort threshold, the one at which you'd be a minority fork
13:44 < jeremyrubin> gmaxwell: have you heard about OP_TIMEMACHINE
13:45 < gmaxwell> E.g. introduce a new, non-standard, transaction version, and if a block contains any transactions with that version it's taken as an indication that the miners consensus rules have been upgraded to handle the new script features.
13:45 < gmaxwell> jeremyrubin: I don't think I have, under that name at least.
13:46 < jeremyrubin> one day, you will have heard of it already.
13:46 < jeremyrubin> gmaxwell: is tx version off the table for that kind of thing?
13:46 < gmaxwell> (which means that if miners don't upgrade their consensus rules, they almost immediately lose fee income. -- opposing it is no longer costly)
13:46 < gmaxwell> I've suggested that idea and it was stridently opposed by bluematt, so I doubt it would make sense to go that way today.
13:47 < jeremyrubin> What were the objections? I've always thought it odd not to use it?
13:47 < jeremyrubin> Concern about requiring segwit ins/outs and not mixing?
13:47 < gmaxwell> I think though if it was the first signaled activation thing we'd done -- the goal really was just to gauge that hashpower had upgraded-- it would have worked out fine.
13:47 < luke-jr> gmaxwell: or they just change policy to ignore versions
13:47 < gmaxwell> luke-jr: sure but they can always false signal. If miners want to disrupt network stability they always can.
13:48 < gmaxwell> jeremyrubin: but thats why ... it encourages false signaling.
13:48 < gmaxwell> (er, thats the objection to it)
13:48 < gmaxwell> (or at least the main one)
13:48 < luke-jr> gmaxwell: ultimately network rules get enforced by nodes. false signalling still coordinates the nodes.
13:49 < gmaxwell> Agreed. But reasonable people can debate this. My own thinking has changed over time, particularly because of the very low levels of p2p spv clients (and their continued totally busted security story)
13:49 < gmaxwell> BIP9 was created substantially due to the false signaling problem of "increment the block nversion", we've certantly cared about false signaling in the past. 
13:50 < jeremyrubin> Stupid idea, but with segwit technically we have two block versions? If miners can commit in the block header to which tx versions they support, they can filter txs they don't easily.
13:50 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
13:50 < jeremyrubin> Maybe a tx + block version allows you to not care if all miners upgrade
13:50 < jeremyrubin> but just that enough to get a tx thru
13:50 < gmaxwell> (the old increment version approach put miners at risk of orphaning because their version was wrong, and because the block header was functionally controlled by pool software not their node, they just updated the version without bothering to upgrade their node in some cases)
13:51 < jeremyrubin> Fair. More of a problem with modern pools flexible tx selection.
13:52 < jeremyrubin> I wonder if theres a way to otherwise 'phase in' a change if a plurality of miners is enforcing the rule.
13:53 < gmaxwell> In any case, I go back to the bigger argument I've been making: there is an infinitude of things that could be done,  but they won't be enough better to justify a long debate. I think it's most likely that taproot does activate without much more than having to nag pools to upgrade, regardless of the scheme used.
13:53 < jeremyrubin> I think also a lot of pools and operators won't weigh in until there's code they should run
13:53 < gmaxwell> jeremyrubin: I think not if you put stability of the network from the perspective of SPV nodes as highly important.  If you don't enforce a rule, you'll build a child block on an invalid parent if an invalid parent is created.
13:54 < gmaxwell> jeremyrubin: I don't think they'll way in at all, unless there is a misinformation fuled public drama. :)  historically miners and pools have said basically nothing about most consensus changes.   They've either deployed them right away, or not deployed them and needed to be nagged.
13:54 < jeremyrubin> I don't have the SPV issues loaded in that well, but seems like a general SPV problem changes or not
13:54 < gmaxwell> s/way/weigh/
13:56 < gmaxwell> jeremyrubin: if there were no SPV validators at all, most of the stability issues would be a moot concern.  So long as the activation took long enough that anyone who cares can be protected,  there wouldn't be any problems with invalid blocks/false confirmations/etc.   (you'd just be left with questions of a change being good or not and likewise)
13:57 < jeremyrubin> Ok I propose that in the next minor release (slated soon) we do a BIP-8 (as defined presently) 1 year default activateontimeout=true activation. Any objections to that?
13:58 < luke-jr> begin height (timeframe) needs to be chosen too
13:58 < gmaxwell> jeremyrubin: probably not the right venue to ask, :)   I expect people to take issue with activateontimeout=true-- but if they don't then I guess thats a sign that it's not the worst idea.
13:58 < luke-jr> probably should study user upgrade patterns for that
13:58 < gmaxwell> You'd probably not want to set the height until implementation(s) have the code merged.
13:58 < gmaxwell> But you can discuss it with height-TBD.
13:58 < luke-jr> gmaxwell: IMO the conditions where ANY activation is appropriate, and one with lockinontimeout=true is appropriate, are identical
13:59 -!- zfrohardt [49539482@c-73-83-148-130.hsd1.wa.comcast.net] has quit [Remote host closed the connection]
13:59 < jeremyrubin> luke-jr: begin can be basically the time of client launch, no?
13:59 < luke-jr> gmaxwell: yeah, I just wanted to be clear that 2021-07-13 isn't something I'd ACK
13:59 < gmaxwell> luke-jr: The argument I'd make against that is that sometimes you're not completely sure and a signaling period gives you more time to learn more. E.g. you see that users are deploying the software rather than sticking with old versions.
13:59 < jeremyrubin> No harm to end users not to upgrade?
13:59 < luke-jr> jeremyrubin: yes, there is harm; rules need to be enforced by the network..
14:00 < luke-jr> gmaxwell: hmm, maybe
14:00 < gmaxwell> jeremyrubin: for taproot I don't see why a user wouldn't upgrade (unless bamboozled).
14:00 < jeremyrubin> Sure, which won't happen for at least a year unless there's bigger adoption of a version?
14:00 < luke-jr> gmaxwell: there's also a possibility of leaving it false and letting users set it with a config flag
14:00 < jeremyrubin> I'm trying to define the minimum possible safe time, rather than guessing 'x months is enough probably'.
14:00 < luke-jr> jeremyrubin: miner adoption is not user adoption
14:00 < gmaxwell> luke-jr: I don't think we ever really know if users support a change until they deploy the software-- since thats how they show their support. So thats a chicken and egg situation and the reason behind the 'modern sf' kind of logic.
14:00 < jeremyrubin> Miners adopting but users not adoptiing is also safe luke-jr
14:01 < luke-jr> jeremyrubin: no
14:01 < jeremyrubin> How would users be harmed?
14:01 < luke-jr> miners-but-not-users is a 51% attack
14:01 < jeremyrubin> How?
14:01 < luke-jr> jeremyrubin: unless a majority users enforce the rules, Bitcoin is centralised
14:01 < gmaxwell> luke-jr: not users opposing, but users not getting around to it yet.
14:01 < gmaxwell> For all you know, 51% hashpower is *already* enforcing taproot. :P
14:01 < jeremyrubin> Miners-not-users in particular for taproot only matters if users try to spend incompatible taproot txs
14:01 < jeremyrubin> gmaxwell: exactly
14:02 < luke-jr> jeremyrubin: or if miners try to do the same
14:02 < gmaxwell> luke-jr: I think it would be more correct to say that if miners help, it's okay if fewer users have gotten around to upgrading yet.
14:02 < luke-jr> gmaxwell: fewer, but not 1%
14:02 < gmaxwell> sure, not 1% :)
14:02 < jeremyrubin> Like I said, just trying to define the min start date, we can add safety margin around that. But I don't see why immediate isn't safe w.r.t. loss of funds
14:02 < jeremyrubin> (start date, not activation date ofc)
14:03 < gmaxwell> but maybe 10% if that 10% includes almost everyone that is accepting transactions with few confirmations, and the other 90% isn't opposed, but just hasn't gotten around to it yet.
14:03 < luke-jr> gmaxwell: dunno, with as few nodes as we have these days, 10% much be too low
14:03 < luke-jr> might be*
14:03 < jeremyrubin> And if we run into a case where miners activate but taproot is unsafe for a wide case of reasons, users can just... not use it?
14:03 < gmaxwell> luke-jr: okay, maybe but I think my point stands...  without miner support you want users much closer to 90%.
14:04 < luke-jr> right
14:04 < gmaxwell> jeremyrubin: no because unsafe taproot with unupgraded users is confirmation-unstable.
14:04 -!- benbenthecarman_ [~benthecar@89.40.181.149] has joined ##taproot-activation
14:04 < gmaxwell> So that isn't solved by "just don't use it".
14:04 < luke-jr> I think he meant just softfork make Taproot invalid outright
14:04 < gmaxwell> so you really do want to at least give everyone who cares sufficient time to upgrade.
14:04 < gmaxwell> or at least make their upgrade really easy.
14:04 < jeremyrubin> Ok here's an idea!
14:05 -!- benthecarman [~benthecar@45.89.175.126] has quit [Ping timeout: 246 seconds]
14:05 < luke-jr> or maybe I misunderstood
14:05 < jeremyrubin> a longer lock-in period. (forget exact term)
14:05 < gmaxwell> One of the reason that consensus features get activated in *minor* bitcoin core versions, is so that users can upgrade more easily without disrupting their operations.  Major versions often make incompatible changes.
14:05 < jeremyrubin> But it can *activate* and then you get at least 3 months from start date to upgrade
14:05 < jeremyrubin> Or 2 weeks if after start + 3 months
14:05 < gmaxwell> So you can have a situation where the user WANTS to upgrade, but when they use the new version their custom apps fail.  And then to work around that they need to be expert enough to know that they can layer nodes, etc.
14:06 < gmaxwell> jeremyrubin: that is a reasonable point, I think.
14:06 < jeremyrubin> I just don't see a reason to not collect signals immediately.
14:06 < luke-jr> gmaxwell: hrm, I wonder if that could be an issue actually
14:06 < luke-jr> if Taproot implementation goes into 0.21, we need to wait until 0.22 before 0.20 is no longer supported..?
14:06 < jeremyrubin> gmaxwell: yes, that's why I named minor version explicitly 
14:06 < gmaxwell> luke-jr: could be? version compatibility has been an issue in the past. Thats also why I advocated for modernsf the second period be totally commandline configurable from the first periods software.
14:07 < luke-jr> activation is trivial to backport
14:07 < luke-jr> it's the implemetnation of the SF itself that might be an issue
14:07 < gmaxwell> luke-jr: I don't think it's reasonable to wait for a support eclipsing... esp because in practice what I see businsesses do is run arbritarily old stuff or current stuff.
14:08 < jeremyrubin> Also I think the whole point of a soft fork v.s. hard is not to require support eclipsing 
14:08 < jeremyrubin> well not whole point
14:09 < luke-jr> it's so that there can be outliers
14:09 < jeremyrubin> but a major point is compatibility, v.s. luke-jr's just make nodes die every 8 years
14:09 < gmaxwell> But generally, you do want to make it easier to upgrade and allow more time to the extent that its not easy.
14:09 < gmaxwell> Keep in mind upgrading isn't the only option: users can use an upgraded node as a firewall in front of non-upgraded nodes.
14:09 < luke-jr> well, consensus cleanup SF could probably be backported today easily
14:09 < luke-jr> Taproot is a bit more complex
14:10 < gmaxwell> I dunno if blockstream kept the model, but when I was there all liquid functionaries were setup to run two bitcoinds for that reason. Liquid software only talked to the internal one.
14:10 -!- mode/##taproot-activation [-s+tc] by ChanServ
14:10 < gmaxwell> and thats a model I've encouraged exchanges to adopt, though I only know of a couple that have-- it can be deployed at the last minute.
14:10 < jeremyrubin> I think the three time windows is a concrete improvement to BIP8? start date: release date. soonest enabled date: release + 1 quarter. timeout: release + 1 year?
14:10 -!- benbenthecarman_ [~benthecar@89.40.181.149] has quit [Ping timeout: 272 seconds]
14:11 < jeremyrubin> In the happy case, people get even more time to upgrade
14:11 < luke-jr> jeremyrubin: I'd want to look at historical upgrade trends
14:11 < jeremyrubin> luke-jr: I think it only matters for releases which have forks?
14:11 < gmaxwell> jeremyrubin: one could construct a variable quieting period. E.g. that it won't ever activate faster than 1 quarter after release, but 6 months in, quieting period is only a week or whatever.
14:11 < jeremyrubin> Because upgrading non fork versions is whatever
14:12 < jeremyrubin> gmaxwell: that's what I think I specified?
14:12 < gmaxwell> OKAY wasn't clear if you just meant making the quieting period longer.
14:12 < luke-jr> jeremyrubin: maybe
14:12 < jeremyrubin> 'soonest enabled' would be std::max(Exact soonest date, lock_in date + 2 weeks)
14:13 < jeremyrubin> so it can't be usable any time before the soonest date, but afterwards it's a normal 2 week period
14:13 < jeremyrubin> You could make it a few steps if you wanted to as well, but I don't see a point in that
14:13 < luke-jr> hrm, my data point is probably an outlier, but not very time-friendly <.<
14:13 < gmaxwell> I'd like to point out that I don't think really long activation periods are great, -- mostly because during that time work on the feature stops, so we don't gain anything from it, except the (very important!) extra time nodes get to upgrade.
14:14  * luke-jr is still using 0.13 for his cold wallet
14:14 < gmaxwell> e.g. the community was *massively* behind on segwit wallet support, because almost no effort went into working on it until segwit activated.
14:14 < gmaxwell> luke-jr: sure and for a cold thing, thats justifyable. (aside, PSBT are nice and will make your life easier)
14:14 < jeremyrubin> gmaxwell: I did some analysis which shows that longer activation periods are, the more benefit there can be for delaying
14:15 < jeremyrubin> This fits into a model for "due tommorow do tomorrow" on adding compat to services
14:15 < jeremyrubin> Longer time doesn't actually get people to do the work sooner
14:15 < gmaxwell> jeremyrubin: but the more it kills development interest and participation in the ecosystem.
14:15 < midnight> luke-jr: +1, PSBT will make your life way better.
14:15 < luke-jr> maybe, but then I'd need to upgrade the wallet :/
14:16 < gmaxwell> past the minimum needed to make things sufficiently safe, longer times just make everyone swap out their knoweldge of the change, etc.
14:16 < luke-jr> besides, I sync the cold wallet when I use it
14:17 < jeremyrubin> gmaxwell: also having some sort of 'regularity' of changes means that cos will likely employ people to work/integrate/test more, v.s. bitcoin being something you can ignore mostly. That's neither good or bad nesc. But I do think all big cos should have someone doing bitcoin-ops full time if possible
14:17 -!- thomasb06 [2ec100e0@gateway/web/cgi-irc/kiwiirc.com/ip.46.193.0.224] has quit [Quit: Connection closed]
14:17 < gmaxwell> I really couldn't tell you how most of the specifics of taproot work anymore (just as an example), the broad ideas sure, but how annex is encoded, or what the limits are on tree depths etc.  Meaning that I'm *less* qualified to review taproot or wallet implemenetions using it than I was months ago, and I think this is true for most people.
14:18 < jeremyrubin> gmaxwell: if the gap is too big, then someone can't find a FT role doing that and organizational aptitude drops
14:18 < gmaxwell> jeremyrubin: right, if there aren't regular changes (or at least trashfires. :( ) then it's rational for people to forget about bitcoin and not invest in being able to upgrade it.
14:18 -!- visa [68f67be8@ool-68f67be8.dyn.optonline.net] has joined ##taproot-activation
14:18 < gmaxwell> right now, pick almost any big bitcoin pool operator and I *guarentee* they can tell you a lot more about the latest ethereum minutia than bitcoin stuff.
14:18 < jeremyrubin> eventually we should get there (like running servers is now just AWS), but it's way to early for that sort of ossification
14:19 < gmaxwell> because the bitcoin stuff just works, fire and forget. Which is good in one sense, but is a ball and chain for any upgrade.
14:20 < jeremyrubin> you probably need like >10:1 ratio of 'how to run eth' people at ******** for every 'how to run btc person'
14:20 < gmaxwell> right.
14:21 < jeremyrubin> You should chat with Taylor at MyCrypto sometime on how they sync eth nodes
14:21 < gmaxwell> so paradoxically, there is an optimal amount of stability that is less than perfect stability.
14:21 < jeremyrubin> IIRC something like having hundreds of them and just killing and forking if it stops syncing
14:21 < gmaxwell> I've talked to other places, e.g. I know some exchanges have a round robin thing when a eth node goes out of sync according to block explorers, they fall over to another one and then automatically reinitilize.
14:22 < gmaxwell> yep. with quick sync, I'm pretty confident that if eth hashpower minted themselves 100M etherer out of thin air, most exchanges would go along with it before realizing what happened.
14:22 < jeremyrubin> Bitcoin RPCs where after 2 years we add random timeouts... just like Apple!
14:22 < gmaxwell> lol
14:22  * midnight chokes on coffee
14:24 < gmaxwell> in any case, thats why I think stuff like matt's softfork(s) would have been good... anything bitcoin does that keeps people upgrading on a somewhat reasonable time schedule has side benefits too.
14:24 < gmaxwell> My general impression is that parties with wallets do upgrade, but parties without wallets (or on their cold wallets) just don't.
14:25 < gmaxwell> I seem to vaguely recall there was a block transaction order change circa 0.17 that should be apparent in blocks.
14:26 < gmaxwell> I'd wager that there is a lot of hashpower running whatever is current post that last media covered CVE.
14:27 < gmaxwell> If someone wanted 'machiavellian SF' instead of 'modern SF'  you'd announce already-fixed CVEs shortly after the consensus change release. :(   (not a suggestion, just a sad commentary that it would be effective)
14:27 < jeremyrubin> ah was just typing that
14:27 < jeremyrubin> Or you'd explicitly introduce CVEs
14:27 < jeremyrubin> So that you can drive your consensus changes without even having to find bugs
14:27 < gmaxwell> There is a less evil version of just issuing a lot of new versions after the change.
14:28 < jeremyrubin> gmaxwell: good point
14:28 < gmaxwell> "Holy fuck dude, you're EIGHT versions behind!"
14:28 < jeremyrubin> We should change our versioning system
14:28 < jeremyrubin> People actually care about being more versions behind
14:28 < gmaxwell> we've actually done that to some degree in the past with unannounced fixes,  ... issued more upgrades to try to get more adoption of the fix.
14:28 < jeremyrubin> Major/Minor distinctions can be mapped project level
14:28 < jeremyrubin> but no "point fixes"
14:29 < gmaxwell> (since other than workload there isn't a particular reason that new versions couldn't come out once a month)
14:29 < jeremyrubin> There's a level of coercion which i think is ok, which is 'apathy is not an option'
14:29 < gmaxwell> in any case, apathy isn't the worst problem in the world.
14:29 < jeremyrubin> just making people aware that 20.0 and 20.01 are very different things
14:29 < gmaxwell> I'd rather have apathetic users than "I made a robot blindly reinit my node and trust hashpower because this shit is unstable"
14:31 < gmaxwell> jeremyrubin: I don't like the extra delay but one possibility is to add the non-activated new consensus rule in x.0  then activate it in (x+1).0 AND x.5 (or whatever is current for x). so you get both the "new major" upgrade bump and the "new minor upgrade bump".
14:31 < gmaxwell> But I think in practice we found that most users are not so bad about upgrading.
14:31 -!- benthecarman [~benthecar@45.89.175.126] has joined ##taproot-activation
14:31 < jeremyrubin> hmm
14:32 < jeremyrubin> maybe
14:32 < jeremyrubin> I think that I do like th idea of a version having a manual enable flag
14:32 < jeremyrubin> so we can deploy something without deployments
14:32 < gmaxwell> mining pools less so, because they have no local wallet.. the worst that can happen from a missed upgrade is some invalid blocks (an expense which they usually pass on to their users!)-- but that ALSO a risk they take when they upgrade.
14:32 < jeremyrubin> but a flag
14:32 < jeremyrubin> so if you can't update you can just restart with the flag at the right time
14:33 < jeremyrubin> but people could be scammed into setting it
14:33 < gmaxwell> right. I think being scammed into activating a softfork is not the greatest thing to worry about.
14:34 < gmaxwell> the bigger problem is that it essentially means you delay activation for a long time after the software is ready,  which has the problem of lost inertia, excitement, and working knoweldge.
14:34 < gmaxwell> it would work better if you merged the change eagerly knoweing that it wouldn't be activated right away so it doesn't need to be 100% perfect.
14:35 < gmaxwell> (but hopefully it's close enough that it'll be compatible if manually activated ... or at least only need tiny patches to make it compatible)
14:37 < luke-jr> indeed
14:38 < luke-jr> even if the BIP isn't final, we could merge the current draft
14:38 < luke-jr> speaking generally; I should go review the code for Taproot
14:38 < jeremyrubin> we already kinda have merged it
14:38 < jeremyrubin> The secp subtree got merged with schnorr right?
14:39 < jeremyrubin> That's the part that's scariest to me
14:39 < gmaxwell> on the subject of taproot merging,  libsecp256k1 really needs more reviewers.  It's my expirence that competent developers radically underestimate their ability to contribute to low level crypto code, treating it as black magic.
14:39 < gmaxwell> jinx
14:40 < luke-jr> gmaxwell: I know I don't consider myself qualified..
14:41 < gmaxwell> I can assure you that *every* person who has made a non-trivial contribution to bitcoin core is actually qualified to find the majority of potential problems that crop up in libsecp256k1... especially when it comes to more serious (rather than purely theoretical) issues.
14:41 < jeremyrubin> Maybe being in a subtree kinda hurts the reviewer base too?
14:41 < luke-jr> gmaxwell: really? I don't even understand how ECDSA works
14:41 < jeremyrubin> I think gmaxwell means that things like the constant time checking were just general software engineering, not crypto math
14:42 < gmaxwell> luke-jr: yes, but you can read! like there is a wikipedia article.  There are comments in the code.
14:42 < luke-jr> hmm
14:42 < gmaxwell> Even some crypto math too-- at least enough to go "hey this looks weird"
14:42 < gmaxwell> most faults are not some exotic algebric magic thing.
14:43 < gmaxwell> anyone reading my text and doubting that you can review crypto code, PM me and I will try to convince you by showing you some vulnerable code that I think if you try, you can find the vulnerablity in.
14:44 < jeremyrubin> I think that part of the uncomfortability is that I would review crypto code but I would never ACK it due to lack of deep math understanding.
14:44 < gmaxwell> (in PM because my example will be an actual live vulnerablity in real but obscure code, unfixed because the author is unresponsive)
14:44 < gmaxwell> You can always give a "I don't know what I'm doing ACK"
14:44 < jeremyrubin> all my acks are already like that probably
14:44 -!- grubles [~blockhash@unaffiliated/grubles] has joined ##taproot-activation
14:44 -!- visa_ [~textual@ool-68f67be8.dyn.optonline.net] has joined ##taproot-activation
14:45 < luke-jr> heh
14:45 -!- visa [68f67be8@ool-68f67be8.dyn.optonline.net] has quit [Remote host closed the connection]
14:45 < luke-jr> gmaxwell: give it a CVE? might get some more attention
14:47 < gmaxwell> AFAICT my specific example isn't actually in production anywhere, but of course it's hard to tell.
14:50 < gmaxwell> I can say that as an author of crypto code, throwing something out and getting zero or little review sucks. The people obviously qualified to review are busy... but really I'm often not confident that I didn't make some totally bone headed mistake like miss an important boundary check where there is at least SOME odds that joe-programmer would either spot the issue or ask the right question.
14:51 < gmaxwell> And after an issue has been found, everyone treats it like it was SO obvious, even when it wasn't.  It's comforting to know that if you are being stupid, at least you're not much more stupid than brillant people like luke-jr. :)
14:55 < gmaxwell> jeremyrubin: it's my opinion that putting it in another repository compromises review somewhat. It has other advantages, but it does cost participation.
14:58 < michaelfolkson> Would be great to have a Bitcoin Core PR review club on libsecp one week gmaxwell. Or an online Socratic Seminar or presentation. If latter I would be happy to organize
15:00 < michaelfolkson> I didn't know until now it needed more reviewers relative to Core itself needing more reviewers. Obviously everything is relative and everything needs more review
15:02 -!- visa_ [~textual@ool-68f67be8.dyn.optonline.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
15:03 < gmaxwell> jeremyrubin basically hit the nail on the head, very few people feel qualified to ack almost anything in that repo, and only do so with fair trepedation.  (which is actually pretty sad, because it's not like that codebase is particularly scarry or fragile-- it's better tested than anything in core overall, for example)
15:04 < roconnor> Perhaps I should start reviewing libsecp code.  I think I even feel qualifed.
15:04 < jeremyrubin> gmaxwell: maybe I'd review it anonymously
15:04 < gmaxwell> jeremyrubin: Better than nothing.
15:05 < gmaxwell> I have to say that I became extremely demoralized working on the library basically firing improvements into the dark.
15:06 < gmaxwell> roconnor: You absolutely are.  In addition to understanding the mathy stuff, your perspective on the language's requirements is extremely useful.
15:06 < jeremyrubin> gmaxwell: where are you spending your time mostly these days?
15:06 < jeremyrubin> where/on what?
15:07 < gmaxwell> Non-bitcoin stuff for the most part. I found the workflow/ecosystem around bitcoin was just making me depressed.
15:11 < michaelfolkson> Do you get frustrated with people struggling to catch up with your level of understanding? I'd guess if you did more educational stuff like Core PR review club it would be less depressing than being abused on Reddit
15:12 < michaelfolkson> Or get bored repeating the same thing over and over again so people don't make the same mistakes?
15:19 < gmaxwell> In libsecp? Mostly just firing things into the dark, and not getting substantive feedback or ACKs.  (in bitcoin core there are other additional issues)   like in 2018 I merge 44 PRs in libsecp and 38 in 2019... but any time I would make a PR, I'd have to continually beg people for months to look at it.  When I'd go out into broader #bitcoin-core-dev, I'd get a response-- sometimes pretty
15:19 < gmaxwell> useful (e.g. from wumpus or luke) but those folks didn't feel confident acking.
15:19 < jeremyrubin> i guess the funny thing is it's still probably an improvement from openssl :p
15:20 < gmaxwell> so basically when I was intrested in working on something, there wasn't really anyone else interested.. And when they would reply it's after a long enough gap that I'd lost inertia on it.
15:21 < gmaxwell> It looks like these days it would be a little better in libsecp256k1 since tim and jonas have been more active.
15:22 < gmaxwell> michaelfolkson: rehashing the same old stuff hasn't been an issue in libsecp256k1... that is a legit thing that happens, for that there has to be a threshold level of activity (and also eager contributors who are sufficiently pushy to make a nussance of themselves)
15:25 < gmaxwell> I think part of the issue is that sipa was the main driver of the repostory, and he's just not that interested in it recently. Nothing wrong with that, but it creates a void in active contributors whom everyone (including themselves) feels qualified to ACK things.
15:27 < jeremyrubin> A bit of cookie licking to an extent
15:27 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz]
15:28 < gmaxwell> implicit cookie licking, in fact.
15:29 < gmaxwell> thats also why when I stopped working on it, I dropped access and wrote the other contributors that I wouldn't be working on it in the immediate future... so on one would be waiting on me when I was burned out on it!
15:30 -!- moneyball changed the topic of ##taproot-activation to: discussion about various activation proposals, community outreach, and general next steps to gain adoption. logs: http://gnusha.org/taproot-activation/ . Technical discussions about taproot itself belong in ##taproot-bip-review.
15:35 < gmaxwell> anyways, schnorr PR is here: https://github.com/bitcoin-core/secp256k1/pull/558
15:35 < gmaxwell> if that gets merged, then the secp256k1 tree is updated, then the taproot PR will probably halve in size.
15:35 < gmaxwell> which presumably will make it less daunting to people.
15:36 < gmaxwell> (actually looks like that PR is more than half the size of the taproot PR)
15:36 < gmaxwell> It's not even all that complex a PR, but it includes tests, build system, and API changes that bloat up its size.
15:42 -!- brg444 [be2ec812@pc-18-200-46-190.cm.vtr.net] has joined ##taproot-activation
15:43 < ja> is schnorrsig really to be gated by the --enable-experimental flag? that gives the impression that taproot is also experimental, no?
15:45 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined ##taproot-activation
15:47 < gmaxwell> Experimental flag mostly means the interface is unstable / no compatibility promises are offered by the library, stuff like that.
15:47 < gmaxwell> Until taproot activates, it's also pretty expiremental! :)
15:48 < gmaxwell> there is this weird problem with crypto code online (surely applies outside of crypto code, but most obvious there), where people post some crazy yolo stuff that was essentially their learning-to-crypto project on github, never reviewed by anyone,  then it gets picked up deployed and relied on by big parties.
15:49 < gmaxwell> bitcoin core uses other non-default flags in libsecp256k1.
15:49 < gmaxwell> (e.g. the signature recovery code-- which potentially infinges a certicom patent)
15:54 < ja> all right, i guess people have to understand 'experimental' in context
15:58 < aj> jeremyrubin: when the 95% was over a rolling 1000 block window there was some chance that something like 85%-90% of hashpower could trigger activation; with non-overalpping sets of 2016 blocks, it's pretty hard to activate at 95% threshold with less than something like 93% of hashpower supporting
15:58 < jeremyrubin> hm? I did the math once I think it's 85% is likely to trigger
16:00 < jeremyrubin> let me see if I can find it
16:01 < jeremyrubin> isn't it just:
16:01 < jeremyrubin> sum([any(numpy.random.poisson(85, 26) > 95) for x in xrange(10000)]) / 10000.0
16:02 -!- benthecarman [~benthecar@45.89.175.126] has quit [Ping timeout: 256 seconds]
16:02 < jeremyrubin> e.g., out of 10,000 trials, if 85% of hashrate want to signal, then poisson(85) is the number of blocks we'd expect to be produced by that set
16:03 < jeremyrubin> so any(poisson(85, 26) > 95) is an indicator that one signaling period activated
16:03 < jeremyrubin> This is like 97%
16:03 < gmaxwell> the intervals aren't indepedant. if they overlap.
16:04 < jeremyrubin> Do they for versionbits? I though it was every 2016 blocks?
16:05 < jeremyrubin> "All blocks within a retarget period have the same state. This means that if floor(block1.height / 2016) = floor(block2.height / 2016), they are guaranteed to have the same state for every deployment. "
16:06 < jeremyrubin> gmaxwell: and I think that would only serve to increase the probability of activating as you'd have more potential windows to activate?
16:08 < jeremyrubin> "These are tallied each retarget period"
16:08 < jeremyrubin> Yeah so I think that the non-overlapping independent interval assumption is correct
16:09 < gmaxwell> no recollection, we debated these cases for a long time-- it wasn't clear to me that you were specifically talking about bip9 above. :)
16:10 < jeremyrubin> ah my bad. Yes, I think the math is correct above that demonstrates that for BIP-9 style versionbits, about 84% of hashrate signalling on all periods translates to a 95% probability of activating.
16:12 < jeremyrubin> aj: Ah I'm re-reading your comment now and realize you're talking about a different rolling window thing
16:15 < jeremyrubin> aj: unless my estimation is off, the numbers can be much lower, the fall off point is around 78 where it drops to 50/50 odds, 75, 1/4 odds, 70 1/20.
16:16 < brg444> just catching up on logs. a bit unnerving reading all of this. lots of "shell-shocked" people around, talks of "war" already. antagonistic language tossed without regards. I hope we can frame this more carefully.
16:18 < gmaxwell> yeah, it's not like the mining industry features armed forces storming company offices. :P
16:18 < brg444> we've learned a whole lot since segwit, people, relations have grown and fortified (as far as I can see). I'm hoping we can leverage this rather than assume the worst already
16:18 < brg444> lol
16:18 < gmaxwell> (jokes aside, I do agree.)
16:19 < aj> jeremyrubin: poisson gives you timings for blocks, but if you just care about whether the blocks are in a given set then it's just repeatedly re-selecting from the same set with probability, which gives binomial distributions
16:19 < brg444> there will always be that one bully :/
16:19 < aj> jeremyrubin: the rolling 1000 block window was used for CLTV and earlier
16:19 < jeremyrubin> aj: that's incorrect and I've made that mistake several times! Poisson counts the occurences, exponential the timing
16:21 < jeremyrubin> Poisson works here because we're sort of 'fixing' the window to exepcted 2 weeks
16:21 < jeremyrubin> In 2 weeks, we expect to mine 85/100 * 2016 blocks
16:21 < jeremyrubin> so poisson(that) tells us how many we got, but we can just use 85 directly
16:22 < aj> poisson counts the occurences per unit time; but we've got a fixed number of occurences and don't care about the time
16:23 < gmaxwell> you're flipping a weighed coins and counting heads, thats a bernouli trial and uses a binomial distribution.
16:23 < jeremyrubin> My guess is that these end up being equivalent expressions, but I can reformulate
16:23 < aj> the 2016 is fixes, the two weeks is just hand waving
16:25 < gmaxwell> s/fixes/fixed/ ?
16:29 < aj> yeah fixed
16:29 -!- slivera [~slivera@103.231.88.10] has joined ##taproot-activation
16:31 < jeremyrubin> Interesting will think it through.
16:36 -!- visa [~textual@ool-68f67be8.dyn.optonline.net] has joined ##taproot-activation
16:39 < luke-jr> gmaxwell: anything in particular in secp that needs review?
16:39 < luke-jr> [22:35:07] <gmaxwell> anyways, schnorr PR is here: https://github.com/bitcoin-core/secp256k1/pull/558 <-- wait, I thought it *was* merged?
16:49 < jeremyrubin> I thought so too, I though that was the subtree update
16:52 < instagibbs> so 558 is the one to look at currently for libsecp?
16:54 < gmaxwell> No, it hasn't been merged, there was a subtree update so that there wasn't a HUGE pile of other changes totally unrelated to taproot.
16:55 < gmaxwell> Yes, 558 is the relevant PR.
16:55 < gmaxwell> (I wondered if perhaps you were making this error, thats why I linked it)
16:57 -!- roasbeef [~root@104.131.26.124] has joined ##taproot-activation
16:58 < instagibbs> ok I'll try to dedicate some cycles to at least looking at API edges
17:11 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
17:22 -!- visa [~textual@ool-68f67be8.dyn.optonline.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
17:35 < roconnor> brg444: Didn't a cartel of BTC.Top Antpool BTC.com and ViaBTC recently propose a "no-debate" BCH fork to redirect 12.5% of block rewards to cartel approved addresses?  What percent of Bitcoin hash power does this cartel own, and what do you think the chances that they would be willing to hinder the depolyment of Taproot if given the option?
17:35 < jeremyrubin> aj: for analyzing BIP-9 using binomial, how do you adjust for how many block periods happen in a 1 year period?
17:36 < jeremyrubin> It seems like the 2 week assumption creeps in in one place or another
17:36 < aj> jeremyrubin: the number of periods is fixed, not the timeframe
17:36 < jeremyrubin> Bip 9 works in MTP not in periods I thought?
17:37 < jeremyrubin> So you could have e.g. 25 periods, 26 periods, 27 periods
17:37 < aj> sure, but there's no reason to do that again
17:38 < jeremyrubin> I'm just curious what the actual math works out to be.
17:39 < jeremyrubin> with poisson i was assuming total periods and length of periods, with binomial you assume the total periods. Two very different answers!
17:41 < jeremyrubin> In particular since the time between 2016 blocks would  seem to be an exponential variable, variance is very high right?
17:41 < jeremyrubin> Maybe this nerd-snipe is off topic for here though :)
17:42 < brg444> roconnor about 30% as of now. while their motivation remains a mystery, I feel pretty confident this group was subdued by the events that transpired 3 years ago and I would imagine they aren't too keen to repeat their past mistake given how costly it was.
17:42 < brg444> may be wishful thinking :/
17:43 < brg444> I'm simply proposing that we use our networks to open communication channels with them if they are willing to engage rather than plot behind their back and paint them as the enemy from the jump
17:44 < aj> if i remember how my code works, then if you've got 85% hashpower signalling, there's a ~99.77% chance any 2016-block period will have between 1664-1762 (82.5%-87.4%) signalling, so even over 26 periods there's only a 5% chance any of the blocks are out of that range
17:44 < roconnor> I definitely support such efforts.  I hope someone can report back and assuage my worries.
17:44 < brg444> it's a delicate issue and I don't think it can be addressed in public channels unfortunately but it's better to try to involve them in those discussion as early as possible. heck, we might be surprised by their feedback/positions
17:47 < brg444> we have a lot more mining friendly figures with bigger weight than in the past too
17:47 < roconnor> I certainly would like to know any constructive critisism miners have with respect to the Taproot proposal.  But ultimately, what is relvent is user depolyment and enforcement of consensus rules and miner support is simply a safety net on top of that.
17:48 < aj> hopefully we aren't doing anything that hurts miners income streams/competitive advantages this time too
17:48 < gmaxwell> it's probably premature to have those discussions until its merged.
17:48 < gmaxwell> aj: Well, except breaking ASIC-Surge.
17:48 < aj> gmaxwell: ...
17:49 < gmaxwell> (I just made it up, in an abundance of pessimism.)
17:49 < aj> gmaxwell: googling that, i get "Criminal charges led by ASIC surge 300%" , ASIC being the .au SEC equivalent
17:50 < gmaxwell> at least once the taproot consensus rules are merged (and ideally activatable in regtest) what is being proposed may not be concrete enough.
17:50 < roconnor> TBH, I don't personally have a that much confidence that miners even validate blocks.
17:50 < gmaxwell> roconnor: they do and don't, you can look at the non-zero existance of invalid blocks and the fact that they haven't been forming chains as evidence.
17:51 < brg444> roconnor while there are some who are coin agnostic and are simply in it for the money, I think it's pretty safe to say that a lot of miners are also users and have a significant network of users around them so it's important to consider that, I think
17:51 < gmaxwell> after miners finally updated to post 0.16 code a lot of the incentive for not validating went away. :)
17:51 < roconnor> what change was that?
17:52 < gmaxwell> roconnor: not one, but were around that time a whole bunch of block propagation and mining logic speedups.
17:52 < roconnor> I see.
17:52 < gmaxwell> you can see the deployment of these changes in graphs of the network visible stale block rate. It's extremely low now.
17:53 < gmaxwell> As in, a node back in 2012 might see a stale block per day... now they'll go several months without seeing one.
17:54 < roconnor> why do you think miners have a significant network of users around them?
17:56 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined ##taproot-activation
17:56 -!- amiti [sid373138@gateway/web/irccloud.com/x-xxenphispxqqcfhv] has joined ##taproot-activation
17:56 < BlueMatt> roconnor: maybe useful to look at it from another direction - sure, miners may ignore things (or even be outright hostile), but also whats the risk in testing first? I dont think anyone is proposing straight up bip 9, so its not like we're taking a risk of non-activation, only delay. if we *presume* we have to end up with a flag day, even, it would be the first flag day in modern time, and we should be thinking hard about how we
17:56 < BlueMatt> think flag days should look.
17:57 < BlueMatt> at least personally, I would strongly hope flag days include a *ton* of time for users to ponder the implications and the support-level.
17:57 < aj> gmaxwell: it's rare enough bitmex does an investigation when it happens, cf https://twitter.com/BitMEXResearch/status/1281515719830777856 https://twitter.com/BitMEXResearch/status/1270413012260786177 ; pretty amazing
17:57 < BlueMatt> (but maybe I'm also more relaxed about delays...at least personally, I dont care about a year or two between friends)
17:58 < roconnor> BlueMatt: Agree.  From my narrow vantage point I think there would be a lot of support for a BIP8-style depolyment, which is effectively a flag day with benefits.
17:59 < brg444> they're pretty significant operations, involving numerous investors, employees. it's a bit unfortunate that so many years later the guys on the other side of the pond remain a bit of a black box but I'd be surprised if everyone over there still treats Bitcoin as a CNY generating operation. I'm just they have their own bulls and their own memes :).
17:59 < brg444> Anyways, getting a bit off-topic
18:00 < BlueMatt> roconnor: bip 8 isnt really "benefits" - it lacks the whole "lots of time for users to decide" bit
18:01 < roconnor> I mean, it could have that time in principle.
18:01 < BlueMatt> roconnor: I cannot imagine a bip 8 deployment in the current design that doesn't have a million idiots deploying nodes with the flag set on day one and bragging about it on twitter
18:01 < BlueMatt> which, imo, is about the worst possible outcome.
18:01 < brg444> I personally wouldn't mind bip9 with short-ish timeline (6 months?) then flag day if it proves necessary
18:02 < BlueMatt> if we want to do that, we should throw out all the effort we've put into arguing that bitcoin isnt controlled by a small community and just start hard forking monthsly
18:02 < BlueMatt> brg444: heh, did you read the "Modern Softfork Activation" thread months ago? :)
18:02 < BlueMatt> brg444: its...pretty much that.
18:02 < brg444> i recall seeing it but I guess it's time to revisit
18:04 < roconnor> I don't really see that as too much of a problem.  Any proposal that doesn't have core developers support wouldn't even be merged to begin with.  I think many users have delegated technical decisions to the software developers of the software they use (applies widely beyond Bitcoin Core), so it is only natural outcome to install the latest versions and get excitted about an upcoming new set of features.
18:04 < roconnor> Taproot itself has nearly zero impact on users who don't want to use it.
18:06 < roconnor> "with the flag set on day one"  maybe I misunderstood this statement.
18:07 < roconnor> My understanding is that BIP 8 is BIP 9 with timeout causes activation and blockheight is used instead of MTP.
18:08 < BlueMatt> roconnor: "any proposal that doesn't have core developers  support wouldn't even be merged to begin with" GAHHHHHHHHHH whut
18:08 < gmaxwell> BlueMatt: uhh duh?
18:09 < roconnor> ??
18:09 < gmaxwell> No one is going to be like "uh, this is terrible and I think it shouldn't fly so I'm going to spend my time developing it, and deloying it, and supporting it,"
18:09 < gmaxwell> what roconnor was saying was essentially a tautology.
18:09 < BlueMatt> i mean if we're at a point where our argument is "bitcoin is safe cause users are gonna scream from the rooftops in belligerint tones in favor of anything core does" seems.......bad
18:09 < gmaxwell> that isn't what he was saying. :(
18:10 < BlueMatt> <roconnor> "with the flag set on day one"  maybe I misunderstood this statement. <-- my understanding is bip 8 currently has some cli/bitcoin.conf option flag thinggy to enable the "activate at timeout" part
18:10 < BlueMatt> to enable a failure path (yay), but which you can set on day one (hmm), and which users will be bragging about having set on day -10 (yuck)
18:11 < BlueMatt> gmaxwell: hmm, maybe I misread the intent, then, sorry roasbeef
18:11 < BlueMatt> roconnor:
18:11 < BlueMatt> wrong ro<tab>...
18:11 < roconnor> BlueMatt: Ya, there was some discussion about that point earlier.  My reading was that it was a depolyment parameter.  I totally agree it shouldn't be a config flag and it would be a disaster if it was.  This is something that needs to be clarified in BIP8 I think.
18:12 < BlueMatt> it was added as a flag precisely because folks pointed out that bip 9 has no failure path, which gives you precisely 0 time to measure upgraded-users
18:12 < roconnor> I was going to say, I believe that Bitcoin Core already merges and depolys software changes that are already much more risky than a Taproot proposal would be.
18:12 < BlueMatt> its a simple hack so that folks can go "oh, wait, nope, no consensus, set flag, now flag day gone"
18:13 < aj> BlueMatt: i don't think bip8 specifies how lockinattimeout is set, and not sure, but i don't think luke's draft activation has a way of setting/clearing it other than recompiling at present
18:13 < BlueMatt> that may be true in the abstract, but consensus changes carry a certain level of risk due to the various failure-modes they have which are unique (forks, users cauht on their own islands, etc)
18:14 < BlueMatt> aj: ah, even worse! or better! solves one problem, breaks another :shrug:
18:14 < aj> BlueMatt: (ie, what it should do there is still totally an open question)
18:14 < gmaxwell> The purpose of having a config parameter on this stuff as I've seen it discussed is so the parameter is *hidden*,  and then if there is community support of using it new versions come out with the new default for it... but also people with old code can just set a hidden config option.
18:14 < roconnor> https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#Parameters lists lockinontimeout in the same section as 'bit' and 'timeoutheight', which leads me to believe the proposal is that these are not configuration or config file options.
18:14 < BlueMatt> right, I think my point is that there is no "right" answer for such a thing. and part of why that scares me is its a relatively quick timeline
18:14 < gmaxwell> so you can get maximally fast deployment of the change.
18:15 < BlueMatt> wait, so does bip 8 still not materially have a failure path?
18:15 < gmaxwell> if there is a legit worry about people rallying users to set the option stupidly, then perhaps it's best to leave it out.
18:15 < BlueMatt> aside from a recompile option?
18:16 < gmaxwell> I still haven't seen anything that changes my position that endless debate on the specifics is worse than just trying something and seeing how it goes.
18:17 < BlueMatt> that may be true, though luckily there isn't code to add a depoyment mechanism too yet anyway!
18:17 < roconnor> IMHO, and I'm sure this is controversial, but it doesn't need a failure path.  We can deal with failure in way we deal with other Bitcoin failures.  If anything we have even more options.  For example, depolying another BIP on a faster timeline to bury segwit v1 before taproot is activated.
18:17 < BlueMatt> so no time wasted :p
18:17 < roconnor> I guess my point is why are we more worried about failure in Taproot more than failure of all the many other software changes that go on in Bitcoin Core?
18:18 < BlueMatt> roconnor: the failure in this case isnt neccessarily a software bug, but a consensus failure
18:18 < gmaxwell> roconnor: consensus rule changes are slower to deploy than other changes.
18:18 < gmaxwell> BlueMatt: other bugs also can cause consensus failures.
18:18 < BlueMatt> as in "oops, we thought this was trivial, turns out lots of folks disagree!"
18:18 < BlueMatt> sorry, other type of consensus failure, I realzied that has two meanings
18:18 < roconnor> Sure but conensus code get changed all the time in Core.
18:19 < aj> BlueMatt: i don't think there's an answer to that question yet. "<luke-jr> gmaxwell: there's also a possibility of leaving it false and letting users set it with a config flag"  from earlier
18:19 < BlueMatt> aj: ah, well fair enough. I think I strongly disagree with it either way!
18:19 < gmaxwell> I think BlueMatt means that taproot might be released and users might go "we don't want this!"
18:19 < BlueMatt> roconnor: other type of consensus failure :p
18:19 < BlueMatt> right, what gmaxwell said
18:19 < gmaxwell> Though I think that is extremely unlikely.
18:19 < BlueMatt> or, even if we think its absurdly unlikely, it should be *possible* to handle such a case
18:20 < gmaxwell> BlueMatt: if that happens, and it activates, softfork it out later. :P (by not allowing new outputs to be created).
18:21 < roconnor> or even softfork out Taproot before it finishes activating.
18:21 < gmaxwell> like, do you prepare for the possibility that dropped luggage from an airplane might hit your head whenever you walk outside?  there is a threshold where excessive preparation is a harm.
18:21 < gmaxwell> roconnor: or that.
18:22 < roconnor> I would even be fine preparing such code to disable taproot in advance, though I think it isn't necessary to do that.
18:22 < gmaxwell> ^ stuff like that can be prudent, ... it's preferrable to handle "impossible contingencies" outside of the critical path.
18:22 < gmaxwell> sure, have a plan for how to abort it.
18:23 < gmaxwell> but it's not reasonable to delay it by 6 months just to polish the impossibilities.
18:23 < roconnor> I mean, we do lose a segwit verison in such a case, but I think it is very unlikely and the cost isn't too bad.
18:23 < gmaxwell> it's not like the BEST POSSIBLE failure mitigation is all that better than "just spend 8 hours doing exactly what roconnor says".
18:23  * BlueMatt notes that one of the major learnings he took out of the segwit debacle is that its virtually unknowable what level of community support exists for a change until it is in a release of core
18:23 < BlueMatt> which I think is my main motivation here
18:24 < BlueMatt> that failure handling *must* be thought of from day one and must be easy
18:24 < BlueMatt> sure, it shouldnt cost us much in the happy case
18:24 < BlueMatt> of course
18:25 < gmaxwell> hm? I think we knew there would be drama from segwit before it was even proposed,  there were things we didn't know for sure. (lol like jgarzik flying to china and holding brieings lying about it -- but even that was long before it was in a release)
18:25 < BlueMatt> which we can discuss specifics of, but I dont buy that the failure handling case should be "eh, new release!"
18:25 < BlueMatt> drama yes. precise level or level of strong disagreement, no.
18:25  * BlueMatt -> pizza
18:25 < roconnor> new release is how we handle existing Bitcoin failures.
18:25 < gmaxwell> ^ I agree.
18:25 < BlueMatt> roconnor: and we've learned very well that that works super poorly :(
18:26 < gmaxwell> I don't agree.
18:26 < BlueMatt> folks dont upgrade :(
18:26 < gmaxwell> They upgrade for SERIOUS ISSUES. (and in gnerally most wallet having parties do upgrade)
18:28 < gmaxwell> It's my opionion that worrying about hopefully unlikely failure cases that could just be handled as they arise has already delayed this proposal by months and meaningfully increased its risk by sapping energy/inertia/development effort from it.
18:28 < gmaxwell> We have a situation where the principle author of the implementation doesn't even care to be in the room discussing the activation.
18:29 < gmaxwell> this is just stupid.
18:29 < gmaxwell> sometimes failure is *created* by spending too much time worrying about it.
18:29 < roconnor> I guess we need to seperate implemenation failures from ... what do you want to call it ... failure of the community to agree on a new consensus rule set?
18:29 < BlueMatt> if sipa doesn't want to participate so what? I dont get why its important to get the details right?
18:30 < roconnor> I don't see taproot implemenation failures from being more risky than existing Bitcoin Core development.
18:30 < BlueMatt> in any case, I think we certainly agree that we shouldn't have a failure of slowing things down in a happy case
18:30 < BlueMatt> that would of course be crazy
18:30 < gmaxwell> because the drama chases away expertise which can be important to avoid making mistakes.
18:30 < BlueMatt> sipa decided that before any discussion happened, I dont see how thats super relevant
18:30 < roconnor> As far as getting agreement on a new consensus rule set, I guess the best we can do is go out and sollicit feedback from known participants.
18:30 < BlueMatt> but also kinda besides the point
18:31 < roconnor> But ultimately I don't see any way around putting it into Bitcoin Core and seeing if it floats.
18:31 < BlueMatt> roconnor: agreed! but I *still* dont think we know even closely what a *lot* of the community thinks, despite optech spending lots of money on trying to do outreach for several years now.
18:31 < BlueMatt> roconnor: as for your last point, I agree! I dont think there's anything we can do to learn that besides shipping it!
18:31 < BlueMatt> and thats ok, lets plan to do that and plan for it to activate quickly
18:32 < gmaxwell> when we solicited feedback on segwit the results were essentially reliable.  Everyone that responded positively deployed promptly.  The parties that responded negatively, didn't.
18:32 < BlueMatt> but, if not also because precedent around *how* changes are made is precisely what defines bitcoin, we should be careful about how changes are made
18:32 < gmaxwell> roconnor: community currently thinks "sure sounds great!"  or  "I don't know what that is and don't care."   it's going to stay that way unless someone makes a big PR effort to change it.
18:32 < gmaxwell> er that was intended to be to BlueMatt
18:33 < BlueMatt> fwiw, optech *has* made a big pr effort to at least get folks to understand and take a position
18:33 < BlueMatt> but, I dont think anyone disagrees that we'll learn the most from shipping it?
18:33 < gmaxwell> as roconnor notes, taproot is essentially irrelevant to people who won't use it and aren't authoring a node.  Other than assorted upgrade costs, it mostly has no effect on non-users.
18:34 < gmaxwell> and to the extent that e.g. it effects a block explorer because it adds a new scriptpubkey -- so does any script improvement.
18:34 < gmaxwell> BlueMatt: what even does "take a position" mean?!?
18:34 -!- visa [~textual@ool-68f67be8.dyn.optonline.net] has joined ##taproot-activation
18:35 < BlueMatt> gmaxwell: errrr, poor wording
18:35 < BlueMatt> "understand and check that they arent actively uncomfortable" maybe?
18:35 < gmaxwell> sure. thats fine.
18:36 < gmaxwell> Ideally most users should be "Sure, sounds fine. I don't care."  if it were the case that most users were "holy fuck, I want that now" -- then the feature is being deployed much too late.
18:36 < BlueMatt> right, but my point is I dont think they would realisically claim that they've hit more than a reasonable portion of community members
18:37 < BlueMatt> agreed, and I think they will be!
18:37 < gmaxwell> Generally it's not any of my business what rules other people use to manage their funds, except in so far that crudding up my nodes consensus code with more rules has a cost.
18:37 < BlueMatt> all the more reason to plan for the happy case :)
18:37 < BlueMatt> right, only concern is complexity and validation time cost
18:37 < BlueMatt> within reason, of course
18:37 < roconnor> I'm trying to figure out the assorted upgrade costs. :D  "costs" like signature checking will be cheaper.  ;)
18:37 < gmaxwell> but at lot of the costs like "you shouldn't do taproot because a better version could be done instead" don't fly given the effort and collaboration that has gone into creating it.
18:37  * BlueMatt is a little bit at a loss for concrete disagreements here
18:38 < instagibbs> roconnor, it's free for people who don't upgrade ;D
18:38 < BlueMatt> gmaxwell: agreed!
18:38 < gmaxwell> yeah, it reduces validation costs.
18:38 < gmaxwell> I don't think there is a case to be made that it worsens either the expected average or worst case costs.
18:39 < gmaxwell> But it is more consensus code to carry around.
18:39 < aj> it only reduces validation costs if batch validation is implemented, which it isn't yet, no?
18:39 < roconnor> aj, yep "will be"(tm)
18:39 < BlueMatt> indeed, you could argue something about reducing miner revenue by decreasing tx size is bad, but, ehhhh
18:39 < gmaxwell> aj: well, it's not implemented in core. it's implemented in a libsecp256k1 PR.
18:39 < aj> well, multisig if musig is implemented i guess
18:39 < aj> gmaxwell: oh!
18:39 < brg444> It may not be an interesting sentiment to cater to but while it's true that most users will be indifferent to the technical details and may never use it, you might be surprised by the amount of support you can garner with "Sure, sounds bullish".
18:39 < gmaxwell> we had that implemented when I still worked at blockstream, in 2017...
18:40 < roconnor> aj: regarding multisig, not really.  Blocks are "more expensive to validate" if there are more checksig operations per byte typically.
18:40 < BlueMatt> anyway, I'm a bit at a loss as to the disagreement here, I think we're aligned on goals, is the only question whether or not its worth having an escape valve?
18:40 < aj> gmaxwell: oh, i thought it had been pulled
18:40 < aj> roconnor: ah, you're right
18:40 < instagibbs> BlueMatt, what's the actual disagreement?
18:40 < gmaxwell> aj: taproot should reduce cost per byte without batching IF people use if for multisig because it doesn't have to do 2#$@# trial and error validation.
18:41 < gmaxwell> aj: it's in a seperate PR from the schnorr PR.
18:41 < BlueMatt> brg444: I think thats quite the anti-feature! bigger blocksize "sounds Very bullish" :)
18:41 < brg444> Users are looking for signals that things are moving, they don't necessarily care in which direction but they being drowned in noise these days and I think you cannot understate how positive of an impact any update might have
18:41 < gmaxwell> "Users are looking for signals that things are moving" < that is a good point.
18:41 < BlueMatt> instagibbs: I'm not quite sure, thats what I want to figure out - I'm a little confused why folks seem to want to go full-flagday
18:42 < gmaxwell> As I've pointed out before, one of the reason that bitcoin journalism is often so bad is that they just aren't fed with enough stuff to write about.
18:42 < BlueMatt> brg444: that may be the best argument for not doing any more forks I've ever heard :)
18:42 < roconnor> instagibbs: I think there might be a (philosphical??) disagreement on whether BIP8 needs an explicit path to failure, or if roconnor wayving his hands saying we can softfork out taproot prior to activation, counts as a good-enough failure path.
18:42 < instagibbs> BlueMatt, if I can figure out, in writing, what the actual disagreements are on what is acceptable, vs what is coptimal
18:43 < instagibbs> roconnor, bip8, as updated, allows failure with one deployment type AFAIU
18:43 < gmaxwell> BlueMatt: also a good way to find out if people oppose something is to attempt to do it.  This is a point in favor of luke's default-to-activate.
18:43 < jeremyrubin> roconnor: I'm happy with it for what it's worth. I think it's reasonable to assuem that people who upgrade will be wary to upgrade again if theres a problem
18:44 < roconnor> instagibbs: True. I think we should never use that depolyment type, and in particular we shouldn't use it for Taproot.
18:44 < brg444> BlueMatt It can be abused for sure but you guys have earned the trust of this community, and they, for the most part, have done a fair job of letting you guys work on obscure stuff without continually harping "WHEN DEFI on BITCOIN!?" so when something has been baking in the oven for a while, they will rally behind it, for right or wrong
18:44 < gmaxwell> like, go implement fail-activated...  and see if someone comes up with a reason to not do that.
18:44 < instagibbs> sorry what's fail-activated :)
18:45 < BlueMatt> <gmaxwell> BlueMatt: also a good way to find out if people oppose something is to attempt to do i <-- thats the pont I've been trying to make for months ;p
18:45 < gmaxwell> right now luke's BIP8 just starts enforcing after a timeout if the feature doesn't hashpower activate before then.
18:45 < roconnor> gmaxwell: *lol* Today I was thinking of proposing a PR to remove these two lines: https://github.com/bitcoin/bitcoin/blob/a79bca2f1fb25f433d6e100a31a3acfde2656ce1/src/consensus/tx_verify.cpp#L19-L20  to see what reasons people would object to it.
18:45 < brg444> pretty much ^^
18:46 < BlueMatt> right, essentially all I'm suggesting is that we should plan for using that release to learn something, and then push off the "decide to go ahead with flag day" decision until after that point
18:46 < gmaxwell> The activate-on-timeout (is that more clear) as least has the advantage that it should bring opposition out of the woodwork, rather than having it sit back and speak up only if the hashrate doesn't go the way it wants.
18:46 < BlueMatt> brg444: I'm really dissapointed with this line of argument. Seriously, it makes me want to suggest a no-forks-ever policy.
18:46 < gmaxwell> BlueMatt: I think you're misunderstanding brg444 but I can't figure out how.
18:47 < jeremyrubin> roconnor: seems like a redundant branch, remove it!
18:47 < BlueMatt> gmaxwell: hmm, thats fair, and certainly there should be a clear "this is highly, highly, highly likely to activate unless you come out of the woodwork"
18:47 < BlueMatt> gmaxwell: hmm, maybe? istm the argument is, basically, "we need news about bitcoin upgrading for the sake of news"
18:47 < instagibbs> So I suggest if there is general aceptance of Step 1, just go with Step 1, argue about Step 2 later?
18:48 < instagibbs> as BlueMatt suggests
18:48 < BlueMatt> gmaxwell: but, to be fair, I dont *think* that doesnt exist in any release with a fork possible via hashrate activation
18:48 < BlueMatt> instagibbs: no, I dont think anyone is proposing that, actually
18:48 < BlueMatt> instagibbs: all discussion right now is basically around Step 2, and presumes that Step 2 should be clarified at least mostly in advance
18:48 < BlueMatt> (which I think is a position I strongly agree with)
18:48 < aj> BlueMatt: (probably better to go on podcasts and the like and tell people (who aren't already contributing core devs) how they should judge/distinguish good/bad ideas without just picking someone they like and trusting their opinion)
18:49 < instagibbs> I don't understand why then
18:49 < aj> BlueMatt: (better than just going with no-forks-ever, i mean)
18:49 < gmaxwell> BlueMatt: Excitement is healthy for purely engineering logistic reasons.  You were lamenting that you weren't totally sure people wanted the change, news is a way to learn that.  Everyone laments that there aren't enough reviewers/contributors, news helps with that.
18:49 < BlueMatt> aj: sure, but I'm sad folks who are otherwise bitcoiners are actively *making* that argument :(
18:49 < gmaxwell> BlueMatt: I was lamenting that many mining pools fire and forget their bitcoinds and are slow to upgrade. News helps with that.
18:49 < instagibbs> If I can't understand what you guys are saying after reading all this :shrug:
18:49 < aj> BlueMatt: smart people are still often wrong
18:50 < BlueMatt> instagibbs: I think the concern is basically that if Step 2 isn't clearly defined in advance, you end up with the segwit situation where folks "block" block blocking Step 1, and presume Step 2 isnt a thing
18:50 < BlueMatt> whereas you can likely derisk that with a well-defined Step 2
18:50 < gmaxwell> BlueMatt: well what luke is proposing doesn't have that problem.
18:50 < brg444> I'm certainly not suggesting we rush development for the sake of news, just saying that indifference is probably not accurate, users will pay more attention if they think it may benefit them indirectly
18:51 < BlueMatt> gmaxwell: fair enough. news is good, but change for the sake of news, especially *consensus* change, makes me very, very, very pessimistic for the future of bitcoin. if we want news, it should be generated with fanzy whiz bang 16-bit graphics in bitcoin core :)
18:51 < BlueMatt> or some lightning news about how people can shove more funds into the currently-actually-quite-unsafe lightning network :)
18:51 < gmaxwell> BlueMatt: but no one is here advocating some bullshit change for the sake of change, so you're worked up over a strawman. :)
18:52 < aj> BlueMatt: get square's design team working on a "magic internet money wizard" loading screen graphic maybe?
18:52 < BlueMatt> gmaxwell: right, I was informing instagibbs what the concern is with "leave Step 2 undefined", which I dont think anyone is suggesting be a good approach
18:52 < instagibbs> I didn't say undefined fwiw
18:52 < BlueMatt> aj: sounds good! can you intor me to square's design team? :p
18:52 < instagibbs> just that if you can agree on broad strokes, we don't have to wait for a merged PR or something
18:52 < gmaxwell> step 1 and step 2 is too abstract for me to make sense of, but I think you're just saying "don't just use unmodified bip9" ?
18:52 < aj> BlueMatt: oh, sorry, it's probably a secret and you don't have clearance
18:53 < BlueMatt> gmaxwell: indeed, step 1 being "bip 9"
18:53 < gmaxwell> I don't think anyone particularly wants that.
18:54 < BlueMatt> gmaxwell: right, I was explaining to instagibbs why :)
18:54 < gmaxwell> But for example. I think I'm fine with luke's bip8 as an initial proposal, rather than working out some complex multiphase thing.
18:55 < BlueMatt> timeline for it aside, I super strongly disagree just in that it doesn't have built-in clear expectation of learning from the initial deployment of software
18:55 < BlueMatt> which I think we all agree will come with at least some learning
18:55 < gmaxwell> instagibbs: BIP9 has bad defaults.  :(  basically it turns pool apathy into a long drawn out failure,  and discourages people who actually oppose from speaking up, because instead of opposing they can instead just try to encourage the failure through the hashrate path privately.
18:55 < roconnor> Does BIP9 buy us anything.  If it succeeds then BIP8 would have succeeded too.  If it fails, do you think we will learn why?
18:55 < roconnor> s/anything./anything?/
18:55 < gmaxwell> roconnor: just gives you more time to get users to upgrade.
18:56 < BlueMatt> roconnor: yes! you do! you'll probably learn that the pools are apathetic (which thy are), but you may learn something else
18:56 < instagibbs> gmaxwell, don't need hte history lesson, I'm just trying to get an explanation of what the disagreements are, since they're fairly inscrutable
18:56 < roconnor> I mean, we need that time for users to upgrade anyways, since miners are just a safety net, and the user upgrades is what matters.
18:57 < BlueMatt> roconnor: my point is that you should learn these things *before* you release software with a forced activation
18:57 < BlueMatt> if we learn only that miners are apathetic, great! release the flagday!
18:57 < gmaxwell> roconnor: per earliest discussion, if miners all upgrade you might only need 10% users upgraded (esp if the 10% included most parties that accept few-confirm payments),  without miners upgraded you really want 90%+ users upgraded.
18:58  * BlueMatt likes "decreasing activation hashpower requirement over time leading to flagday" for ^ reason :)
18:58 < roconnor> *lol* Okay I suppose I'm not used to trusting miners to validate blocks.  It makes me feel uneasy.
18:58 < gmaxwell> it should. :)
18:58 < BlueMatt> roconnor: as it should! but miners also prevent forks and network splitbrains during soft forks as users upgrade
18:58 < BlueMatt> or, at least, can.
18:59 < gmaxwell> but realistically almost the big economic players will upgrade. ...  it's perfectly rational to trust miners if you're not even accepting transactions right now! :)
19:00 < gmaxwell> BlueMatt: I don't think working out the details of varrious staged things are worth their delay.
19:00 < gmaxwell> (or worth the effort to analyize or reason about them)
19:00 < roconnor> gmaxwell: How so?  The issue isn't accepting transactions, rather it is forked networks?
19:00 < gmaxwell> roconnor: if you're not accepting a transaction you don't care if the network is forked. Your payment will replay on both sides, and its on the recipent to decide if they're happy. :)
19:01 < BlueMatt> gmaxwell: hmm, that may be the case, and I could likely be convinced that things should be simplified, but I dont think I could be convinced to ship a flag day without previous learnings from the same fork being activate-able on mainnet.
19:01 < roconnor> and if you are receiving transactions?
19:01 < gmaxwell> BlueMatt: you also have to consider the implicit signal sent, like if there is 1001 pages of engineering on dealing with opposition that is sending an extremely strong signal that you expect it to fail, which is itself a reason to oppose the whole proposal.
19:02 < BlueMatt> heh, that may be getting a bit *too* game-theory-y for me, but, i wont disagree with simplification on principle :)
19:02 < gmaxwell> roconnor: you care if you're recieving, and my point was that in a case where the logic activates, MOST parts that recieve significant amounts will be diligant with their upgrades,  because if you are accepting payments all the time and not keeping your systems up to date, you're gonna be eaten by hackers. :)
19:03 < roconnor> BlueMatt: It seems like if miners are apathetic then BIP8 would just activate in 1 year time, which is what we want in the apathetic case.  And if there is a looming disater we can soft fork out taproot before it activates.
19:03 < roconnor> And if there is a disater that only appears after activation, BIP9 wouldn't have saved us either.
19:04 < gmaxwell> meh, this isn't especially meta.  Predators attack things that run, because the things that run know that they are tasty and will lose a fight. :)  Don't false signal that you're tasty and will lose a fight if you're not.
19:05 < roconnor> gmaxwell: thanks. I think I get it now.  Or at least it is starting to sink in.
19:06 < gmaxwell> BlueMatt: refining what roconnor says,  not just "we" but users can softfork it out if they have cause to.
19:07 < BlueMatt> roconnor: I dont buy that for several reasons, a) I dont think you can realistically fork out the activation with a new software release on a compressed timeline - its kinda a self-referential timeline - we expect soft forks to roll out on timeline X, but we need to make sure we have X within the same in order to fork it back out... and, much more importantly, b) I do not, not, not, not buy that this is a healthy behavior for
19:07 < BlueMatt> bitcoin core to have (or the bitcoin community to accept from it) - we should take every chance to disavow unilateral flag-day activation without strong *broadly-understood* evidence of consensus. others should be able to observe the level of support that we believe a fork has before a release which fixes it.
19:07 < gmaxwell> BlueMatt: I reject your position. Under your logic no change to the code (esp not consensus code) can ever be permitted:  It *might* introduce a serious bug, and you're saying that it cannot be fixed.
19:08 < BlueMatt> maybe I didn't sufficiently articulate before that part of the goal isnt just for us to feel comfy with the level of support for a fork, but also for the broader community to as well - something I hope we would expect from it.
19:08 < jeremyrubin> I think another way of looking at this is we ship code all the time. When there are bugs in that code, we ship bug fixes. Not having "true conesnsus" is a bug, so we can patch away the issue with another upgrade.
19:08 < roconnor> I still don't get why give this level of scrutny to taproot as opposed to, say replacing levelDB with sqlight?
19:08 < gmaxwell> ^ yes. Also, not just "we" -- someone who cares.
19:08 < instagibbs> I also don't think you're going to get meaningful feedback, due to those reasons
19:08 < BlueMatt> gmaxwell: it might, sure, but if we're planning to learn from the deployment, we cant just ignore that having to fork it back out is a possibility
19:08 < jeremyrubin> gmaxwell: yeah. I suspect that would be 'we' but can be anyone
19:09 < instagibbs> it's really transparent to companies/users who don't want it
19:09 < instagibbs> s/don't want/won't use/
19:09 < BlueMatt> roconnor: no one is proposing replacing leveldb with sqlite, though :)
19:09 < gmaxwell> BlueMatt: sure having to fork it back out is a possibility, but other than making the timeout sufficiently far out-- what else is there to do about that?
19:09 < BlueMatt> not committing until we're even *more* confident its not a realistic outcome short bugz
19:09 < roconnor> uh.. my understanding it that it is somewhat under consideration.
19:09 < gmaxwell> BlueMatt: if someone was, there wouldn't be some weird "half release and solicit community feedback" stage though.
19:10 < jeremyrubin> yes isn't achow101?
19:10 < BlueMatt> in any case, my point (b) above is much more important
19:10 < BlueMatt> roconnor: only thing I saw was bdb being replced with sqlite for the wallet, nothing to do with consensus, but maybe i missed it
19:10 < gmaxwell> ^
19:11 < roconnor> But this consensus rule change isn't intended to harm anyone, and if it does, then it is a bug that is just as bad as any other bug that occurs when changing consensus code.
19:11 < gmaxwell> but the point remains.
19:11 < gmaxwell> right.
19:12 < gmaxwell> taproot should be a no-op to people who don't want to use it.
19:12 < BlueMatt> true, to some extent, but we've also already seen noise about how taproot may be "regulatorily bad" or some shit
19:12 < gmaxwell> roconnor: one difference is that it requires coordination across multiple implementations -- to the limited extent that multiple implementations matter.
19:13 < BlueMatt> which may be something we learn makes it impaletable to some users, and whether we agree or not with that, it liekly merits discussion
19:13 < achow101> jeremyrubin: roconnor: sqlite is only for the wallet
19:13 < gmaxwell> BlueMatt: see, by saying that stuff (which I know you believe to be bullshit) you're running from the lion.  Basically be expressing fear to shit you know is bullshit and you think is an obscure concern, you validate it.
19:13 < BlueMatt> more importantly, I dont buy that this is how we should expect bitcoin to operate
19:13 < achow101> unless someone wants to add it to something else, but I don't
19:13 < roconnor> BlueMatt: And you beleive that a BIP 9 deployment would elicit such a discussion?
19:14 < BlueMatt> roconnor: absolutely! why wouldnt it?
19:14 < gmaxwell> BIP9 is bad for learning.
19:14 < roconnor> I mean it might.  But people might not notice until after activation.
19:14 < BlueMatt> gmaxwell: eh, maybe? point being these are the types of things that we might learn, and such classes of things exist, and they may likely not apply in taproot, but we're also setting precedent for how other soft forks might occur
19:14 < gmaxwell> If you want to block a feature that activates under bip9, you're best off paying 100k to each of three mining pools and calling it done.  .. rather than spending countless hours trying to debate with people or whatever.
19:14 < roconnor> I certainly didn't know anything about Signal PIN numbers until it was deployed with an unavoidable nag screen.
19:15 < BlueMatt> I know you may not aggree that anything done sets a precedent, but I think thats also how we set bitcoin up for future success.
19:15 < gmaxwell> so why even make your issues public? just privately lobby or bribe a few pools to not signal for it.
19:15 < BlueMatt> if its bip9 + will activate soon unless you speak up, then you'll hopefully speak up
19:15 < BlueMatt> (I dont think anyone is suggesting "just bip9" anymore)
19:15 < gmaxwell> if you believe that there is no serious reason to not deploy it-- and want to know if someone disagrees, then act faithfully to your belief.
19:16 < gmaxwell> okay then we're just violently agreeing perhaps.
19:16 < BlueMatt> hmm?
19:16 < BlueMatt> i believe we've de-synced
19:16 < gmaxwell> 02:15 < BlueMatt> if its bip9 + will activate soon unless you speak up, then you'll hopefully speak up
19:16 < jeremyrubin> I think if you wanted to attack Bitcoin's ability to "run faster than the bear" you would attack it precisely with upgrade mechanisms that take too much time because they can be co-opted and bribed out cheaply
19:16 < gmaxwell> is luke's BIP8. it activates on timeout
19:16 < roconnor> BlueMatt: Sure, and to be clear, I don't oppose BIP9 followed by BIP8.  I just think it is a waste of time.
19:16 < BlueMatt> the *only* point I care strongly about is that no flag day should be fixed prior to a release with mainnet-activation possible
19:16 < BlueMatt> "will activate soon unless you speak up" can be accomplished without it being fixed in code.
19:17 < gmaxwell> that is just inviting drama. it's falsely signaling that the people publishing it don't expect it to activate.
19:17 < BlueMatt> roconnor: I could likely be convinced that timelines should be chnaged, thats just bikeshedding.
19:17 < jeremyrubin> Maybe make it a command line flag day and just let people pick their favorite block height
19:17 < gmaxwell> and it's kinda absurd to do given what we know right now: litterally no one is saying don't activate this.
19:17 < jeremyrubin> If you think there's a credible flag day group sooned, decrtement yours ;)
19:17 < BlueMatt> jeremyrubin: thats what I was proposing (kinda sorta) :p
19:18 < gmaxwell> BlueMatt: instead, why not do luke's thing... make it public.. and then don't release that code if people crop up and say they don't want it to activate (with credible reasons, of course)
19:18 < BlueMatt> gmaxwell: presume someone is suggesting an extension block. I dont want to have to, yet again, argue all day long that "you UASF idiots just force-activating this isn't the way bitcoin can or should operate" again :(
19:19 < gmaxwell> jeremyrubin: thats the fucking BU "emergent consensus" and it provably doesn't converage absent another consensus mechenism.
19:19 < BlueMatt> and I especially dont want to have to argue that on the basis that people are "just using bip 8, there's even precedent for it!"
19:19 < gmaxwell> BlueMatt: the criteria is the existance of a meaningful argument against it though.
19:19 < jeremyrubin> gmaxwell: that's sort of the point. If any in-code fixed consensus is bad, you're sort of ending up relying on external consensus
19:19 < BlueMatt> now, bip 9 with 1.5 years to go and a release six months later with it swapped out to bip 8, sure!
19:20 < jeremyrubin> FWIW i think BIP-8 with a fixed activation time is fine
19:20 < BlueMatt> gmaxwell: to you and me, sure, to the UASF folks on twitter, it wasnt even at that time!
19:20 < roconnor> BlueMatt: Thanks I better understand you position.  I still think that for Taproot specifically, and this may not hold for all soft forks, that there is not harm to non-users and there isn't a legitmate concern about coercing anyone into anything.
19:21 < gmaxwell> alsp for taproot specifically, as we stand today, because there is no known credible opposition.
19:21 < BlueMatt> roconnor: maybe, yea. but thats also what all the morons suggesting a 2-month flag-day softfork activation of segwit were saying :(
19:21 < gmaxwell> my opinion would switch to 9->8 if there was.
19:21 < BlueMatt> (nevermind the folks yelling at them that that would be quite network-splitting in many cases)
19:21 < BlueMatt> gmaxwell: you mean 8->9 :)
19:22 < BlueMatt> oh, no, you mean what i described above, sure
19:22 < BlueMatt> but, in any case, if your concern is over timeline primarily, whats an extra 6 months, I mean not like we haven't been talking about this for 3 years.
19:22 < roconnor> BlueMatt: 2-month flag-day is unreasonably short activation period. :)
19:23 < instagibbs> additional machinery is the dispute, no?
19:23 < BlueMatt> roconnor: and yet folks sold hats that said otherwise, must be a bogus distinction! :p
19:23 < gmaxwell> right, the difference is that AFAIK taproot is essentially a no-op to non users *and* there is no credible objection. (and there was for segwit, even though it was stupid it was not trolling)   If it was announced that bip8 was being used, and complaints came up, great that might be a reason to drop taproot completely or switch to 8->9 (if they were real but stupid)
19:23 < BlueMatt> instagibbs: eh, thats not quite how I understood it - bogus machinery that *takes material time*, though, yes.
19:23 < jeremyrubin> BlueMatt: an extra 6 months is a lot if we're setting a permanent expecation to always just add 6 months here or there
19:24 < BlueMatt> jeremyrubin: I think you and I have very different conceptions of time :)
19:24 < gmaxwell> it's taken too long already.
19:24 < BlueMatt> agreed, but also, user count is going to be very low for the first two years anyway. and the precense of a soft fork set to a flag day in-flight does not preclude work on other things
19:25 < jeremyrubin> BlueMatt: things take lots of time and adding 6 months here or there is not good, even if it seems small relative to how long taproot has already taken
19:25 < gmaxwell> well part of the reason user count will be low is that inertia has been lost and people aren't even confident that it will activate, so no wallet support is being written.
19:25 < BlueMatt> (and I'm the one who should be most excited, I get to throw away 20 corer-cases of stupid in lightning implementations due to the lack of schnorr)
19:26 < instagibbs> jeremyrubin, 6 months here or there simply for optics* (which it kind of comes off as, though im sure not charitably read)
19:26 < BlueMatt> jeremyrubin: 6 years, to me, is an astoundingly cheap price for setting a good community norm for how forks operate (especially given we can work on other things while we wait, cause they're guaranteed to activate after a few months of discussion)
19:27 < roconnor> But we should get something for those 6 months, but as far as I can tell all we are getting is the hope that someone will crawl out of the woodwork with some crediable reason why they are affected negatively by other people choosing to use taproot.
19:27 < roconnor> It's nearly unfathomable.
19:27 < BlueMatt> hope? no, guarantee that they wont, including in future changes.
19:27 < jeremyrubin> 6 years is like > half the life of the project. If all changes take that long I suspect many here will quit bitcoin.
19:28 < jeremyrubin> Not sure that's a good norm either
19:28 < gmaxwell> s/will/have/
19:28 < gmaxwell> it's great to take more time TO MAKE THINGS BETTER. but these sorts of delays actually make things worse.
19:29 < BlueMatt> to be fair, I also dont really see how a 1 year timeline for a flag day activation is ok - we have strong evidence that not nearly a significant majority of nodes upgrade by then.
19:30 < aj> roconnor: isn't that replacing bdb with sqlite (wallet code, not consensus code)
19:30 < BlueMatt> maybe its close to ok, but I'm dubious its definitely enough
19:30 < aj> ah, achow already said
19:30 < gmaxwell> aj: roconnor's point would hold, there would not be a big public call for responses for replacing leveldb with sqlite.
19:30 < jeremyrubin> BlueMatt: consensus rule changing upgrades and non consensus rule changing upgrades have different upgrade window
19:31 < BlueMatt> jeremyrubin: I dont think we have super strong evidence that user upgrade cycles are different for either (loud hat-sellers notwithstanding)
19:31 < gmaxwell> aj: I wouldn't say taproot is equivilent, but it's also not entirely disjoint. The reasons someone might not want to deploy taproot are because it might be buggy and break all the things, and that goes for theoretical sqlite change.
19:32 < jeremyrubin> It's also not super neccessary to upgrade
19:32 < jeremyrubin> they'll still sync the network
19:32 < BlueMatt> if its a flag day, it absolutely is!
19:32 < jeremyrubin> So what if a user doesn't upgrade?
19:32 < BlueMatt> thats why bip 9 exists - to use hashrate to derisk a flag day splitbrain
19:32 < jeremyrubin> You just care about economic majority
19:33 < BlueMatt> no, supermajority
19:33 < jeremyrubin> But there is a well defined semantic for segwit v1 under existing nodes. They'll stay on the main chain and still be able to send and receive funds
19:33 < roconnor> aj: There are two distinct reasons to abort in BIP9.  1 is an implemenation error, which I claim is analgous to deploying errors in consensus code, which is the risk we take on on a regular basis.
19:33 < aj> roconnor: in your opinion, for what value of x 2 is an x-month flag-day a reasonable activation period?
19:34 < BlueMatt> no they wont - by definition you have a reasonably amount of hashrate *not* enforcing your rules, the network will have more regular reorgs and users may lose coins because of it (luckily standardness rules protect some, however)
19:34 < roconnor> (2) would be some sort of disagreement with regards to the new consensus rules.  But for Taproot, which is designed to be harmless to non-users, I'm having a hard time swallowing the possible existance of such an honest disagreement.
19:34 < jeremyrubin> BlueMatt: not the scenario I'm talking about
19:35 < gmaxwell> roconnor: also, you'd also have to swallow that (2) exists and yet is unown at the time the release with the activation is put out.
19:35 < jeremyrubin> We're saying what's the harm if majority (or super maj) uprade, straggler upgrading users don't matter
19:35 < BlueMatt> roconnor: this random irc room is not who gets to decide what is or isnt a harmless design
19:35 < gmaxwell> BlueMatt: no one is talking about "this irc room" tap root has been in extremely public discussion for a very long time.
19:35 < BlueMatt> jeremyrubin: sure, under bip 9 - the same is not true for the flag day activation semantic of bip 8
19:36 < gmaxwell> https://www.google.com/search?q=taproot+bitcoin  google says there are 500k results.
19:36 < BlueMatt> (or any flag day activation method - which I think at this point everyone here agress is likely neccessary)
19:36 < instagibbs> BlueMatt, who do you imagine is going to suddenly stumble onto taproot and discover this issue based on more outreach?
19:36 < BlueMatt> instagibbs: I believe you've missed the point - I dont believe that, but I dont believe that others are as confident as us
19:37 < gmaxwell> also to the extent that this mythical flaw finder exists,  there are good odds that he won't waste his time looking at it until he hears that it's defantly going to activate.
19:37 < BlueMatt> instagibbs: in order for a flag day activation to be deployed by users, they should have the level of confidence, or close thereto, that we do now
19:37 < gmaxwell> definitely*
19:37 < roconnor> aj: I didn't quite understand your question.  If I was put on the spot to decide a flag day period, I would say 2-years, but I'm hoping people have more informed opinions, and I'd like to defer to them if I can.
19:37 < jeremyrubin> BlueMatt: not sure I appreciate the difference here
19:37 < BlueMatt> jeremyrubin: in response to what?
19:37 < jeremyrubin> [7/13/20 19:35] <BlueMatt> jeremyrubin: sure, under bip 9 - the same is not true for the flag day activation semantic of bip 8
19:37 < gmaxwell> so if you actually care about exposing disagreement, you should say this is absolutely going to activate unless there is disagreement.  Otherwise, why would the disagreeing party even look at it.
19:38 < jeremyrubin> Maybe even BIP-8 is safer in that regard than 9 gmaxwell
19:38 < jeremyrubin> You could think "surely the network will reject this crap" with 9
19:38 < gmaxwell> Yes.
19:38 < jeremyrubin> And then be surprised when it doesn't
19:38 < BlueMatt> gmaxwell: its also about demonstrating that no such disagreement exists. I believe no such disagreement exists, I know you do too, I *dont* know that bitmex engineers believe that.
19:38 < jeremyrubin> instagibbs: hi
19:38 < BlueMatt> so, in some ense, its about the show of the deployment
19:39 < gmaxwell> BlueMatt: The way to validate that isn't to suggest maybe it will activate but to say it will and challenge people to explain why it shouldn't.
19:39 < gmaxwell> otherwise why speak up?
19:39 < gmaxwell> Why even look at it?
19:39 < aj> roconnor: that's exactly my question, thanks. (i don't see how anyone could have particularly well informed opinions without us trying it more often)
19:40 < roconnor> aj: others probably have a better idea what the typical upgrade pattern for bitcoin core releases is.  It certainly is a tough problem.
19:40 < BlueMatt> jeremyrubin: you were arguing that you only need an "economic majority" to activate a fork, I pointed out that, for the purposes of this discussion, we're talking about a flag-day, ie something which activates ignoring miner thresholds (and, in the bip 9 case, actively *not* meeting miner thresholds). I do not buy that a simple "economic majority" is a safe threshold for such an activation
19:40 < BlueMatt> gmaxwell: agreed! but I do not buy that there is a mechanism for "saying that it will" besides an actual release of core contining it, at which point it is too late to have people understand that there is a lack of disagreement.
19:41 < aj> roconnor: problem is, upgrade patterns probably change when there are soft-forks activating, especially if new features get wallet support
19:41 < roconnor> aj: presumably there wouldn't be wallet support until (well?) after activation?
19:41 < aj> roconnor: (they could be faster than otherwise due to new desirable features; or slower than otherwise due to big changes making the code more risky)
19:42 < BlueMatt> gmaxwell: and I dont think that its unreasonable to believe that people would reasonably expect to have heard *something* about how a change is negative by the time a bip 8/9/42 activation window starts going if such an objection existed
19:42 < aj> roconnor: could be third-party wallets using the new features that require new bitcoind to relay their txs *shrug*
19:42 < BlueMatt> so, the fact that an activation window begins is likely sufficient, in my view, regardless of what type of activation window
19:42 < roconnor> aj: did segwit transactions get relayed after activation?  I guess so.
19:42 < gmaxwell> BlueMatt: the 500k google results (or whatever the real number is) is better at feeling out the public than some release of core.
19:43 < jeremyrubin> Well a simple majority, majority, and supermajority are all different things. It's also an economic majority, as opposed to a noses majority. So it presumes most hashrate. if most hashrate flag activates, then we'd already have this problem.
19:43 < BlueMatt> but I do *not* believe that simply screaming from optech brunches about it makes people feel comfortable that no such objection exists, and, thus, deploying flag day parameters prior to an activation window seems strange
19:43 < aj> roconnor: yeah, a bunch of txs targeted the first block for bragging rights iirc
19:43 < jeremyrubin> As pointed out earlier, 51% miners could already be running taproot and we wouldn't know
19:44 < BlueMatt> gmaxwell: likely true, but I would be willing to bet you could easily find a bitcoin meetup in korea that wont hear about it until its in a release
19:44 < roconnor> aj: Right, I remember those. I'm assuming they were relayed, though in principle they could be mined.  I strongly supect that sipa's transaction was relayed though.
19:44 < BlueMatt> gmaxwell: or, really, any non-english-speaking bitcoin meetup
19:44 < aj> roconnor: s/a bunch of/two/ https://bitcoin.stackexchange.com/questions/61482/what-was-the-number-of-the-block-in-which-segwit-got-activated-and-first-transa
19:44 < BlueMatt> except maybe german or french just given the communities there
19:45 < jeremyrubin> BlueMatt: but the only network risk is if that's a mining community right?
19:45 < aj> BlueMatt: ruben does outreach in korea, so i'd guess they have a better idea than average...
19:45 < jeremyrubin> If it's just a regular user node it's not ideal but it's not like they lose money
19:45 < roconnor> BlueMatt: It's not just screeming form optech, it is all that *and* taproot is specifically designed to be unobjectionable.
19:45 < BlueMatt> jeremyrubin: huh?! wait, we must be de-synced here - are you suggesting its an ok outcome for a fork to activate when there is a large (>5%) part of hashrate not enforcing it when you have a material (< significant majority) of users (by really any metric) who accept transactions *not* enforcing it?!
19:45 < roconnor> I know that being designed doesn't make it necessarly so.
19:45 < roconnor> But it helps.
19:46 < BlueMatt> aj: alright, lets say china. in the past the language barrier has been....a depressingly large issue
19:46 < aj> BlueMatt: (sure)
19:46 < jeremyrubin> I'm saying it doesn't break the network operationally.
19:46 < jeremyrubin> And if the issue is getting time to upgrade wrong
19:46 < jeremyrubin> Users do eventually upgrade
19:46 < BlueMatt> roconnor: it does help, absolutely agree, though it would be great if that were more deliberately communicated :)
19:47 < jeremyrubin> Especially when their software is a couple versions out of date
19:47 < jeremyrubin> So probably the user issue self resolves
19:47 < roconnor> BlueMatt: +1
19:47 < BlueMatt> jeremyrubin: uhhhhh, anyone not in that "only a regular majority" runs a very significant risk of being defrauded. that seems like a really, really terrible outcome.
19:47 < jeremyrubin> How? A block won't get confs?
19:47 < BlueMatt> "you have to upgrade, cause there's a new version, or you lose funds!"
19:48 < BlueMatt> I'm really confused what you're saying jeremyrubin
19:48 < BlueMatt> jeremyrubin: 5% of hashrate non-enforcing means you could totally get to 2 confirmations, and a ton of (likely poorly informed, but acting based on past experience) folks accept payment at 1 conf
19:50 < jeremyrubin> can't you already lose money this way though?
19:50 < jeremyrubin> It's not particularly new to this circumstance
19:51 < BlueMatt> it being possible to have two block reorgs does not imply that we should make decisions that actively encourage them.
19:51 < jeremyrubin> Just generally, 5% of rogue miners can steal from 2 block confers
19:51 < aj> not-upgraded doesn't mean rogue
19:51 < jeremyrubin> I don't think this encourages that outcome?
19:51 < jeremyrubin> Non standard txs aj
19:52 < jeremyrubin> you'd have to be putting those in your mempool which are spending segwit v1, which you don't support
19:52 < jeremyrubin> so you would be rogue
19:53 < BlueMatt> but we've also seen miners with real hashrate running with tx validation disabled :(
19:53 < BlueMatt> at least today they're ver unlikely to get confirmations
19:53 < BlueMatt> in your world that may not be true
19:53 < BlueMatt> in any case, I'm not sure how we're disagreeing that its good to avoid situations where you risk users losing funds for not upgrading on a very tight timescale
19:53 < aj> without a soft-fork you need the rogue miner to control 5% hashpower to mine an invalid block, and then have 5% chance of extending it to 2 confs. with an incomplete network upgrade where 5% haven't upgraded; any block the rogue miner mines has >5% chance of getting to two confs, even if the rogue miner has 0.1% hash power and gets just one block per week
19:54 < jeremyrubin> We're not, I just don't think it's a risk introduced by a flag day
19:54 < BlueMatt> we've literally seen it play out on mainnet
19:54 < jeremyrubin> That evidences my point, no?
19:55 < jeremyrubin> It happens with or without an upgrade?
19:55 < BlueMatt> no, we saw it *because of* an upgrade
19:55 < BlueMatt> and miners do not enforce standardness rules on blocks, recall
19:55 < jeremyrubin> They should enforce it at the mempool
19:55 < jeremyrubin> But I agree that they may not
19:56 < aj> https://bitcoin.org/en/alert/2015-07-04-spv-mining#cause is the reference i think
19:56 < jeremyrubin> My point is that the miner themselves has to be the one trying to deceive, not some user submitting txns to them
19:56 < BlueMatt> :headexplode:
19:57 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has left ##taproot-activation ["Ex-Chat"]
19:57 < jeremyrubin> I'm not trying to make you nuts and appreciate the context you've shared
19:57 < jeremyrubin> Oh
19:57 < jeremyrubin> :(
19:59 < jeremyrubin> aj: > 5% because the rogue miner keeps on mining it for 2 block periods under first seen rule?
20:00 < aj> jeremyrubin: 2 confs = 1st conf by rogue miner, 2nd conf by unupgraded-node + rogue-miner. only need %ge hash power for 2nd conf, %ge working on 1st conf just determines how frequently you can retry
20:00 < jeremyrubin> ah
20:01 < jeremyrubin> I see what you're saying
20:01 < jeremyrubin> so should actually be the other way around
20:01 < jeremyrubin> 1st conf by dumb unupgraded miner
20:01 < jeremyrubin> is incompatible?
20:01 < jeremyrubin> And then a rogue miner attacker can see this
20:01 < jeremyrubin> And then realize someone has already done half the work
20:01 < jeremyrubin> and then amplify?
20:01 < aj> unupgraded miner shouldn't mine a bad block unless they violate standardness rules
20:02 < jeremyrubin> Yeah that's why I thought it's relatively hard for a non adversarial miner to do this
20:02 < jeremyrubin> like if you simply haven't upgraded you'll still mine valid blocks
20:02 < aj> if you're mining non-standard txs that have been invalidated by a soft-fork, i'm happy to count /that/ as rogue, same as if you do SPV mining indefinitely
20:03 < aj> if you haven't upgraded, you'll mine on top of invalid blocks, increasing the power of someone else's attack
20:03 < jeremyrubin> ah right
20:03 < jeremyrubin> so I see what you're saying
20:03 < jeremyrubin> rogue starts, then gets helped by all other un-upgraded
20:03 < jeremyrubin> so then it's % rogue + %un upgraded
20:03 < aj> yeah, exactly
20:05 < aj> it's only when the % un-upgraded is larger than 5 that i think it's a problem -- coinbase does 3-confs so, 10% unupgraded would give 1% odds of attack succeeding (and the cost of attack is mining a block that will be invalidated eventually)
20:05 < jeremyrubin> Also it's not a problem for coinbase
20:05 < jeremyrubin> As they will likely track upgrades
20:05 < jeremyrubin> But generally see the point
20:06 < jeremyrubin> Thanks for helping clarify the logic of how this can lead to loss of funds.
20:06 < aj> well i'm using coinbase as an example of how many confs people wait for in the real world, i guess
20:06 < zmnscpxj__> rogue sacrifices its block subsidy+fees though?
20:06 < aj> zmnscpxj__: yes, "cost of attack"
20:06 < jeremyrubin> # of confs you should use definitely should be influenced by "am I running the latest software"
20:06 < aj> zmnscpxj__: "cost of attack * prob of success < revenue from successful attack" == bad
20:06 < jeremyrubin> I guess the question is, to circle back
20:06 < jeremyrubin> the probability of a BIP8 upgrade failing in this mode
20:07 < zmnscpxj__> so if you are accepting a very large amount of Bitcoin ---> wait for 6 confirms maybe?
20:07 < jeremyrubin> (chunk of hashrate not upgrading) and then the probability of this attack getting realized
20:08 < jeremyrubin> I *personally* weight the combo of those two as being low enough to not really care, but I guess there's room for different thought processes.
20:08 < aj> zmnscpxj__: "cost of attack ***DIVIDED BY*** prob of success < revenue from successful attack" == bad    geez
20:08 < zmnscpxj__> or cost of attack < revenue from success * prob of success makes more sense
20:09 < aj> zmnscpxj__: 7BTC block reward, 2% chance of success --> 350 BTC per attacking block
20:09 < jeremyrubin> Seems like a lot. But maybe you scam lots of little people at once?
20:09 < jeremyrubin> But are there even that many hourly active btc users
20:10 < zmnscpxj__> ah, lots of little people, yes
20:10 < aj> jeremyrubin: well, there's two super safe ways to activate: all the miners upgrade so probability of multiple confirms ~= 0; or all the users upgrade, in which case nobody even sees the attacking blocks. if you do forced activation, you're no longer sure if all the miners upgraded; and if you do it quickly, maybe that doesn't give enough time for users to upgrade, which is where the problem is. 2
20:10 < aj> months definitely too short. 5 years definitely long enough. sweet spot? wtf knows
20:11 < zmnscpxj__> so.... is that what the discussion is at this point? BIP8 at ____ months lockinontimeout=true? or something else?
20:12 < zmnscpxj__> I get the sense BlueMatt wants BIP9 of ___ months followed by 6 months followed by BIP8 of ___ months lockinontimeout=true
20:12 < jeremyrubin> well you also use versionbits still to trigger unknown upgrade warnings right?
20:12 < zmnscpxj__> I think that will be removed because of overt asicboost messing with versionbits...?
20:12 < luke-jr> zmnscpxj__: eh, that'd be stupid complex for no reason
20:13 < aj> https://github.com/ajtowns/bips/blob/201902-sf-signal/bip-sigsf.mediawiki   is a write up of modern soft forks; which is bip8-lockinontime=false for 12 months; 6 months nothing; and bip8+lockinontimeout=true for 24 months
20:13 < zmnscpxj__> how is this diferent from bip8+lockinontimeout=true for 42 months, for example?
20:14 < aj> if i can pull myself away from irc i'm going to update that to have a decreasing threshold in the second phase and post that; but i think luke's bip8 for the first phase seems like it makes sense either way
20:14 < aj> zmnscpxj__: you have to opt-in to the second phase; if you don't opt-in you just get bip8-lockinontimeout=false for 12 months and that's it
20:15 < jeremyrubin> aj: not sure if anyones nodes has 30 months of uptime yet though
20:15 < luke-jr> aj: how is it different from lot=false for 42 months, possibly setting it =true after 18 months?
20:15 < jeremyrubin> Which is I think part of the point
20:15 < aj> zmnscpxj__: the low 13 bits (bip-320) aren't being messed with by miners
20:16 < aj> luke-jr: transitions to failed after 12 months, rather than 42 so that if there's clear consensus to not activate, the code can be dropped sooner
20:17 < zmnscpxj__> Since "transition to failed" is indistinguishable from "nobody really bothered", is that not substantially the same still?
20:17 < luke-jr> well, frankly 42 months is clearly too long <.<
20:17 < jeremyrubin> I'm OK with 42 months if we can at least deploy things in parallel and stop with the serial changes only stuff?
20:17 < zmnscpxj__> If it does not activate in 12 months, we start discussing to remove the code or set lot=true at 18 months?
20:17 < jeremyrubin> But I do think 42 mo is on the quite long side
20:18 < aj> zmnscpxj__: presumably we're discussing that before the 12 months are up, but yes
20:18 < jeremyrubin> I also think that if it's looking like an unlikely activation we'd probably never go for it since the new-new would be ready by then
20:18 < luke-jr> pretty sure if 42mo were to happen, there would be a UASF to activate it sooner
20:18 < jeremyrubin> luke-jr: observation or threat :p
20:18 < luke-jr> the community won't tolerate 42m wait
20:18 < luke-jr> jeremyrubin: observation
20:18 < zmnscpxj__> "fork you"
20:19 < luke-jr> also, UASFs can't be a threat ?
20:19 < luke-jr> if users want to activate it, it's users' right to do so
20:20 < luke-jr> and it seems to me users are clammoring for Taproot yesterday
20:20 < zmnscpxj__> yes, though my impression is that at least some of them are under the mistaken impression it enables cross-input signature aggregation
20:20 < zmnscpxj__> But taproot is great, I want to use it too, yummy MuSig.....
20:21 < luke-jr> zmnscpxj__: well, realistically, any delay on Taproot would probably delay that too
20:22 < aj> i'm certainly delaying working on c-i sig agg until taproot's done
20:22 < aj> yeah, okay, i need to close irc if i'm going to do anything. l8r. (luke-jr, answer your emails ;)
20:22 < zmnscpxj__> c-i sig?
20:22 < luke-jr> aj: I treat email like mail, not like IRC ;)
20:23 < zmnscpxj__> ah, cross-input
20:23 < luke-jr> oh, lol, I totally forgot the older email <.<
20:23 < jeremyrubin> also gonna sign off, catch y'all later. Sorry if anyone felt pestered! I think it's good to explicitly lay out assumptions and threats though
20:24 -!- brg444 [be2ec812@pc-18-200-46-190.cm.vtr.net] has quit [Remote host closed the connection]
20:27 < gmaxwell> BlueMatt: I still don't see why you think releases are special, people really don't hear about the content of releases. They're not a very effective communications tool.  Ambiguity if a thing is real or not, is a thing which releases adress, but I think tats an argument for luke-jr's approach.
20:27 < gmaxwell> Because a form that might not activate "isn't real"
20:28 < gmaxwell> like long after segwit was released e.g. major wallet vendor saying they hadn't looked into segwit because it wasn't clear if it would ever activate
20:29 < zmnscpxj__> right, loss of impetus.  or impetus getting derailed into UASF instead of pestering wallet writers to implement
20:29 < gmaxwell> I should revise my earlier comment, with appropriate quotes google results for taproot go down to 150k, though that still is a tremendous number.
20:30 < gmaxwell> Right, and wallet authors implementing is probably the one remaining likely avenue to discover serious flaws in the proposal.
20:31  * jeremyrubin how many google results is enough to merge
20:32 < gmaxwell> lol
20:32 < gmaxwell> jeremyrubin: obviously not my argument, but I think the idea that the public doesn't know about this doesn't really stand up to analysis.
20:32 < gmaxwell> I don't know what the optimal amount of public attention is... bringing full public attention to everything isn't good either.
20:33 < gmaxwell> grandma shouldn't be talking about segwit.
20:33 < gmaxwell> having all this branded jargon that all bitcoin users are expected to know turns bitcoin into technical soup.
20:34 < midnight> long as it's easy for users to learn as much as they want to
20:34 < gmaxwell> A _user_ will never use taproot, they'll use foo-bar-multisig or whatever other useful thing is constructed out of taproot.
20:34 < gmaxwell> sure I'm not saying it should be hidden.
20:34 < midnight> \o
20:44 -!- ryan84 [ac3a6587@172.58.101.135] has joined ##taproot-activation
20:44 -!- ryan84 [ac3a6587@172.58.101.135] has quit [Remote host closed the connection]
20:45 -!- ryan45 [ac3a65f2@172.58.101.242] has joined ##taproot-activation
20:54 -!- ryan45 [ac3a65f2@172.58.101.242] has quit [Ping timeout: 245 seconds]
21:01 -!- visa [~textual@ool-68f67be8.dyn.optonline.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
--- Log closed Tue Jul 14 00:00:20 2020