--- Log opened Sun Jul 19 00:00:26 2020
01:23 -!- slivera [~slivera@103.231.88.10] has joined ##taproot-activation
01:37 -!- rdymac [uid31665@gateway/web/irccloud.com/x-fasvjyjtbkoqaehj] has joined ##taproot-activation
02:05 < felixweis> 9.7%
02:05 < zmnscpxj__> thx
02:31 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
03:53 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
03:57 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
04:11 -!- slivera_ [~slivera@103.231.88.10] has joined ##taproot-activation
04:14 -!- slivera [~slivera@103.231.88.10] has quit [Ping timeout: 240 seconds]
04:51 < harding> What's the next step on actually selecting an activation method?  I was thiking about creating a page for the Bitcoin wiki that summarized various proposals (e.g. BIP9 (6 month and 12 month variations), BIP8 (several variants based on time and lockin defaults), modern SF activation, bip-decthresh, and maybe other things (let me know); then putting a table at the bottom like https://en.bitcoin.it/wiki/P2SH_Votes and https://en.
04:51 < harding> bitcoin.it/wiki/Segwit_support#Developers where people can indicate whether they they think each particular proposal is Favored, Acceptable, Unfavored, Unacceptable, or Unevaluated.  Do y'all think that would be helpful?
05:23 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
05:32 -!- Netsplit *.net <-> *.split quits: mol, nickler
05:35 -!- nickler [~nickler@static.219.205.69.159.clients.your-server.de] has joined ##taproot-activation
05:39 < darosior> I personally think it would
05:42 < belcher_> harding i was thinking of doing a similar thing but for businesses and merchants instead, but then brg444 convinced me that it wouldnt be that useful
05:43 < belcher_> the reasoning being that it was public for all this time we'd be better off waiting for people to object, rather than actively canvassing them
05:44 < belcher_> on the other hand, does that mean we're meant to just wait for a PR with code to be opened?
05:45 < belcher_> rethinking this, yes such a page would be useful harding
05:56 -!- slivera_ [~slivera@103.231.88.10] has quit [Remote host closed the connection]
07:16 < harding> belcher_: if the someone doesn't want to wait, they can: (1) open the PR to Bitcoin Core themselves; (2) create a fork of Bitcoin Core with the activation parameters they want.  Anyone doing either of those things without gaining the support of a lot of other people is probably going to be wasting their time, which is why I think we've all be having this discussion---we're all trying to find an activation proposal behind which
07:16 < harding> rough consensus can form.  That's why I'm suggesting a non-binding and crude wiki survey---from the discussions here during the past week, I think there might be a proposal that most of the people here can agree on, or which won't cause active opposition or people to stop contributing to Bitcoin.
07:24 < roconnor> harding: I'm trying to write a comment and having trouble expressing my thoughts here.  So I'm going to shorten it to say that I think what is more valuable is a list of reasons why some people think some activation methods are better than others.
07:25 < harding> roconnor: sort of like a FAQ about activation methods?
07:25 < roconnor> maybe.  I was struggling to make a concrete suggestion on how to realize what I'm suggesting.
07:28 < roconnor> For example. I think BIP8(false) 12m is worse than both BIP8(false) 3m and worse than BIP8(false)24 month because BIP8(false) 12m doesn't leave enough time to do a BIP91 style forced activation, which BIP8(false) 24m or longer does.  And while BIP8(false) 3m also doesn't have enough time to do a BIP91 activation, 3months is enough time for miners to normally activate things and doesn't unduely delay moving onto the next step.
07:29 -!- fiatjaf [~fiatjaf@2804:7f2:2a83:3b59:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 272 seconds]
07:30 < roconnor> And I think BIP8(false) 24m or longer is better than BIP8(false) 3m, because BIP8(false)24m lets a BIP91 style forced activate leverage all those nodes in support of taproot that are running the first tarpoot activation release.  And in the unlikely case we decide to abandon taproot due to no support, activate BIP8, then there is little harm in letting the version bit hang in limbo for 2 to 4 years.
07:33 -!- fiatjaf [~fiatjaf@177.205.197.19.dynamic.adsl.gvt.net.br] has joined ##taproot-activation
07:34 < harding> Maybe an attribute based description of each proposal where each attribute links to a description of its tradeoffs?  E.g.  BIP(false)_3m -> {Short duration, Not mandatory, Not lock-in-able}.  Short duration pros: fast feedback; cons: ?; Not mandatory pros: abortable if problem described; cons: even if strong user support, miners may not signal readiness out of apathy; Not lock-in-able pros: none(?); cons: miners may not signal
07:34 < harding> readiness out of apathy.
07:34 < roconnor> Some people think staring with BIP8(false) rather than BIP8(true) is better because it makes it plainly clear that developers aren't dictating the rules, and they need either collaboration with the miners, or we see user support before doing a BIP91 (in the case of long BIP8(false)) or BIP8(true) activation (in the case of short BIP8(true)).
07:35 < roconnor> Other people think starting with BIP8(false) means appathetic miners who have well over 5% of the hash rate have no reason to perform the upgrade and will just stall and that we might as well start with BIP8(true) to show that they will have to eventually update.
07:36 < roconnor> BIP8(true) short time I don't think is advocated by anyone as it doesn't provide enough time for a large number of users to upgrade.
07:36 < harding> I was thinking that if we had a wiki survey that showed there were several ideas that were broadly acceptable, we could all just agree on a provably fair dice roll and go with whatever that selected without further debate.  :-)
07:38 < roconnor> Anyhow, I think the considerations behind the proposals are more interesting than the proposals themselves.
07:42 < darosior> I think too and fwiw that's why I think a wiki page was a good idea: to echo these meaningful discussions to those that are not actively following them.
07:42 < roconnor> harding: How about this:  Categorize the activations by their first intial step, which are I think BIP8(true) long (2y-4y); BIP8(false) short (3m); BIP8(false) medium (1y); BIP8(false) long (2y-4y).
07:44 < roconnor> describe how they can be followed up on. IE. BIP8(false) medium can be followe up in accordance with the MSF activation plan;  BIP8(true) long can be followed up with softforking out the taproot version in case of problems;  BIP8(false) can be followed up with BIP91 activation.
07:44 < roconnor> and describe their pros and cons.
07:45 < harding> Sounds reasonable.  I'll see if I can get a rough draft of that up today.
07:46 < aj> roconnor: "With bip8(false) 3months, all those client updates .. end up wasted in a sense" -- I think that's a *benefit*. bip8/false/short is to see if near-unanimous hashpower activation works because it doesn't require everyone to update first, so there doesn't need to be special effort in getting people to upgrade that would then be wasted on failure
07:47 < roconnor> i.e. how they are affected by miner appathy, what are the optics of deployment,  how long it takes to get deployed under various circumsatnaces.  I'm sure there are other considerations for pros and cons.
07:47 < roconnor> aj: I don't see how that is better than bip8(false) 2y.
07:52 < harding> With BIP8(false)_3m, if it fails, you get to tweak your code after those three months without burning a segwit version.  With 2y, any tweaks need to use v2 segwit.
07:54 < aj> roconnor: bip8 has a nice property that as long as you choose the same time, whether you lockinontimeout=false/true, if any node sees a particular chain as valid/deployment-active, every node will do so, so there's no game theory "well, we'll screw over the uasf'ers, but then activate after"; doing a long bip8(false) either loses that property, or locks the bip(true) approach into the same
07:54 < aj> timeframe
07:54 < harding> Though I guess you do get v1 segwit back at the end of the two years.
07:57 < aj> harding: do a quick soft-fork to invalidate signalling on the versionbit that would have activated that you don't want to activate somehow maybe
07:57 < roconnor> aj: I don't see the need to lock bip(true) into the same timeframe.  If you want to achive a bip(true) in a shorter timeframe (and agree that you want this option), then use a BIP91-style activation.
07:57 < aj> harding: if you've got some way of knowing the long timeout activation won't activate, you can coordinate a soft-fork to ensure it doesn't activate; but i don't really see how you have any way of knowing that
08:00 < harding> aj: if it's fundamentally broken I think you can be sure it won't activate and that nobody sane will want it activated, so coordination in that case wolud be easy.
08:00 < aj> roconnor: bip91 allowed miners to reduce the hashpower required to lock in a soft-fork; it's not a user-enforced activation a la bip8(true), unless you mean something different to how bip91 worked
08:01 < roconnor> aj: By BIP91-style I mean a BIP8(true) softfork that forces the orginal BIP8 taproot to signal all blocks.  Clearly I need a better term to convey this.
08:03 < aj> roconnor: bip91 was "let's signal using bit 4 with a 80% threshold and on success then we'll orphan blocks that don't signal bit 1 for the next x blocks" (or maybe it was different bits)
08:03 < aj> roconnor: bip148 was the "as of date X, every block must signal"
08:04 < roconnor> aj: you are right in that me using BIP91-style to mean, force-signal-the-version-bit-of-taproot-activation is not a great shorthand.
08:06 < roconnor> In anycase, however you want to call it, the bip8(true) approchs doesn't have to be locked into the same time frame because they can softfork with another version bit that forces the orginal version bit to be signaled early.
08:07 < roconnor> and hence BIP8(false) 2y is superior to BIP8(false) 3m.
08:09 < aj> roconnor: a problem with doing it at different times is it loses the "i'm committed to this" part of the game theory. when you're doing the UASF at the very last period, backing down means you lose 100%, so there's no reason to do that. if it happens in the middle sometime, then miners can call your bluff and there's a good chance instead of saying "no, i'll stick to my guns" you'll say "okay,
08:09 < aj> i'll try again later". but if you can't make the "activate or else" ultimatum stick, then you just end up following the miners
08:10 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
08:10 < aj> roconnor: that is, obviously, not a formal proof; but the current bip8 with a single ultimatum/no-ultimatum and no flexiblity on time, does that really well
08:11 < aj> roconnor: and yeah, bip91 where *miners* decide to bring stuff forward, without influencing the user's ultimatum is fine, but if the miners are only doing that because the users made an ultimatum, then users need to be able to credibly make that ultimatum
08:12 < roconnor> I don't see why miners wouldln't take a forced-activation-of-taproot-bit BIP8(true) seriously but would take a take BIP8(true) plain taproot seriously.
08:12 < aj> huh?
08:12 < aj> bip91 isn't bip8(true)
08:13 < roconnor> let's forget about BIP91.  I regret using that term.
08:13 < aj> the 20% of miners who aren't signalling for bip91 take the 80% of miners who do seriously, because the 80% of miners who do are committing to orphan the 20%'s blocks
08:14 < aj> miners take bip8(true) seriously because (ideally) 100% of exchanges/users/etc will ignore their blocks entirely
08:14 < roconnor> exactly.
08:14 < roconnor> that's what I mean by forcing-early-activation of tarpoot.
08:15 < aj> i don't think you get 100% of exchanges/users/etc upgraded in any timeframe that could reasonably be described as "early"
08:16 < roconnor> Indeed, there is no way to have early activation without miner support.
08:16 < roconnor> But surely if miners will activate BIP8(false) 3m within 3 months, then they would also activate BIP(false) 2y within 3 months.
08:16 < roconnor> (maybe you wish to dispute that).
08:17 < aj> btw, based on luke's stats page, of Satoshi nodes (including ones that have unreasonable versions like 0.0.x or 1.x or 2.x or higher) 99% are running 0.13.0 to 0.20 ie versions released in the past four years
08:18 < aj> roconnor: i think things tend to get done by the deadline, so would quibble.
08:20 < aj> roconnor: but my concern isn't that, it's that the bip8(false,2y) might make the user's ultimatum (bip8(true), dec-threshold, whatever) less credible and cause problems when the attempt to have mandatory activation is reached
08:20 < roconnor> Okay I think that is fair.  However, if you are willing to continue, let us take this claim that "surely if miners will activate BIP8(false) 3m within 3 months, then they would also activate BIP(false) 2y within 3 months." just for the sake of argument.
08:22 < aj> roconnor: i guess i'm not /that/ concerned. the real reason is more "there's a lot of complexity in figuring out a sensible uasf method; let's be sure that it's really needed first (and hopefully find out a little more info about why it's needed while we find out if it's needed)" ?
08:22 < roconnor> aj: Is it fair to say that you are arguing that BIP8(false) 3m followed up by BIP8(true) 1y is better than BIP8(false) 2y followed up with a forced-early-activation-of-taproot?
08:23 < roconnor> harding: BTW, I think maybe BIP8(true) medium (1y) might also be on the table as a first inital step.
08:24 < aj> roconnor: i think bip8(true,anything) going into core ought to be a non-starter, really
08:25 < aj> roconnor: as opposed to bip8(default=false,whatever) which a user can override, and we maybe change the default later
08:26 < roconnor> oh okay.
08:27 < aj> roconnor: when i say bip8(false,n months) i mean the user can't override it to true (without recompiling anyway)
08:28 < roconnor> aj: you plan is to put consesnus critical parameters inside a user configurion file?
08:28 < roconnor> (now I think putting that into core ought to be a non-starter)
08:28 < aj> roconnor: (i am having troubling answering your bip8(false,3m)+bip8(true,1y) vs bip8(false,24m)+(something)" question
08:29 < roconnor> aj: understandable as my (something) involves putting a bip8(true) or similar thing into Bitcoin Core.
08:30 < aj> roconnor: if we want to be the same as everything else we can have devs decide what consensus is. if we don't, then user's need to be able to decide on consensus changes, so yes, that means consensus critical params inside a config file (or users choosing to run the "UASF" bip148 fork instead of core or similar)
08:30 < roconnor> aj: after all, if we observe a significant take up of the initial BIP8(false) 2y Bitcoin Core version, I don't see why Bitcoin Core wouldn't follow it up with something to enforce activation.
08:30 < harding> I also think putting a bip8(true, any duration) into Bitcoin Core is a non-starter, but it might be worth summarizing as I think several people here besides roconnor have described that.
08:31 < roconnor> ha okay.
08:31 < harding> s/into bitcoin Core/into Bitcoin Core initially/
08:31 < belcher_> just to check, bip8(false) is the same thing as bip9 ?
08:31 < aj> roconnor: the approach matt proposed in modern softfork activation is that the "bip8(false,12months)" release can have a param that you tweak to switch it to "bip8(true,42months)" so that if the forced activation is going ahead, you can update the config rather than having to reinstall
08:32 < harding> belcher_: basically, yeah.  The only real difference is BIP8 uses block heights and BIP9 uses median time past.
08:32 < belcher_> ah
08:32 < aj> roconnor: (i think it'd be good to make that also require you to put in a block hash from the ~12 month point so you can't just set it as forced activation from day 0, but whatever)
08:32 < roconnor> But this is a softfork that only activates unallocated segwit versions.  It is an all but harmless consensus change.
08:33 < roconnor> And requiring users to corridinate activation themselves sounds like a freaking disaster waiting to happen.
08:34 < aj> every consensus change should be "harmless", that's not very distinguishing. could say thing "only takes unallocated OP_NOPs" too to cover CSV CLTV and CTV
08:34 < roconnor> aj: Softforking out OP_CODESEPARATOR would be an example of a consensus change that wouldn't be harmless, but still plausibly might be something we want to do.
08:36 < roconnor> If Bitcoin Core is unwilling to put a bip8(true) in under any circumstances, and I understand that you folks do not speak for Bitcoin Core, then the cynic in me, who has little faith in miners, belives that taproot will never activate.
08:36 < aj> roconnor: "we want to do" -- if we're talking about "consensus", then if there's people being harmed, they won't want it, and you don't have consensus
08:37 < harding> roconnor: sorry, I modified what I said above to "initially".  I think after 6-18 months of non activation for no good reason, there'd be more than enough rough consensus to do so.
08:38 < aj> roconnor: there's a difference between putting it in as the first activation attempt, and as a second attempt or as a second phase, in either case presumably having had significant feedback from the first attempt/phase
08:39 < roconnor> aj: BIP8(false) 2y followed by forced-activation-of-taproot doesn't mean putting it in on the first activation attemp.
08:39 < harding> roconnor: also, didn't you find a bug in OP_EVAL (a soft for that only changed a NOP to an OP) that at least would've been able to crash random nodes?  Isn't there a risk that taproot or any segwit version change could have a similar effect?
08:40 < aj> roconnor: have you read matt's modern soft fork emails in detail?
08:40 < roconnor> If we do get signfiicant feedback then we wouldn't initiate the force-activation-of-taproot.
08:41 < roconnor> harding: AFAIU I complained about OP_EVAL before it was deployed, but maybe someone can double check on that.
08:41 < harding> roconnor: it was merged but not released.
08:41 < roconnor> I count that as complaining before it was deployed.
08:42 < harding> Sure, me too.  My point is that, if you or someone else hadn't complained, it could've been deployed and then users with no intention of using OP_EVAL would've been affected, which is also possible with changes like taproot and tapscript.
08:42 < roconnor> aj: perhaps not in detail.
08:43 < roconnor> harding: such things happen every time consensus cricital code is touched, not just during soft-forks.
08:43 < roconnor> *such things risk happening
08:44 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
08:45 < aj> roconnor: it's "3)" in his mail fwiw
08:46 < harding> roconnor: sure, that's also a risk, but there the risk is solely in making a technical mistake that produces non-equivilency.  With a deliberate consensus change, the risk is in imposing rules on users to which they don't consent.
08:47 < aj> roconnor: a consensus change means every nodes consensus critical code gets touched in order to remain a full-node; an optimisation just means some nodes get updated. more importantly if an optimisation is buggy, it's easy to back out; if a soft-fork is buggy, it's a hard-fork to undo, or permanent tech-debt to paper over
08:47 < aj> well, permanent tech-debt, and a rushed soft-fork activation
08:48 < roconnor> aj: "if an optimisation is buggy, it's easy to back out"  This is false.
08:48 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
08:49 < roconnor> harding: what exactly do you think taproot would be imposing on users?
08:50 < harding> The obligation to support taproot-compliant spends from v1 segwit outputs for the indefinite future.
08:50 < harding> Basically the same argument you make about P2SH scripts that might be using OP_CODESEPARATOR.
08:51 < roconnor> harding: but how is that obligation meaningfully different from thier current obligations (beyond the fact that schorr signature will be faster and easier to validate batch verification)?
08:52 < roconnor> harding: oh no very difffernt OP_CODESEPARATOR means the currently deployed P2SH scripts could become unspendable.
08:52 < roconnor> (which was my complain to Matt)
08:54 < harding> roconnor: anyone who wants to understand how the system works will now need to learn about key aggregation, key tweaking, schnorr sigs, and MAST-like things.  As someone who's spent quite a lot of time learning about them myself, and then an even larger amount of time trying to explain them to other people, I strongly believe that's a non-trivial burden.  Of course I think it's worth it in taproot's case, but I don't think it's
08:54 < harding>  a free ride.
08:55 < aj> roconnor: well, easy is a spectrum. would you really not say that backing out the consensus-critical locking limits change is massively easier than backing out op_codeseparator inefficiencies though?
08:55 < roconnor> harding: technically key aggregation doesn't belong on your list, but your point still stands.
08:55 < roconnor> (ke aggregation only needs to be understood by people who want to use taproot.  People who want to validate taproot need not learn it)
08:56 < harding> Additionally, if taproot does have a major problem, it's possible it will hurt people I like and make it harder for me to spend my bitcoins, even if I don't use it directly.
08:56 < aj> if you don't do key aggregation you need to learn NUMS point in order to make taproot multisig secure
08:56 < harding> roconnor: fair enough, re: key aggregation (I initially wrote that list differently and should've edited it better).
08:56 < roconnor> aj: Right again for thoses wanting to use taproot.  But the discussion was imposing rules on those who (presumably) are not intersted in taproot.
08:57 < roconnor> harding: no worries.  Your primary point still stands.
08:57 < roconnor> adding taproots makes implementing Bitcoin more difficult.
08:58 < roconnor> meaningfully more difficult.
09:00 < aj> roconnor: if you want to be involved in multisig things with other people, and they start using taproot, you need to know it? (so, lightning in particular, but maybe atomic swap protocols or trusted counter-signers or similar things too)
09:01 < roconnor> aj:  so the arguement would be that hypothetically people could oppose taproot because they will lose their lightning peers to those people who want to save money on their lightning scripts by using taproot?
09:02 < roconnor> and if such people do exist in abunance then this is considered a good reason.
09:03 < roconnor> (I suppose if they exist in abunance then maybe it has to be a good reason).
09:05 < roconnor> [11:28] <aj> roconnor: (i am having troubling answering your bip8(false,3m)+bip8(true,1y) vs bip8(false,24m)+(something)" question
09:05 < aj> roconnor: i don't think taproot is harmful; if i did, i wouldn't support it as a softfork. but i also don't think it's a trivial change, that there's no possibility anyone will find a problem with.
09:06 < zmnscpxj__> if you want to be involved in multisig things with other people, and taproot makes it cheaper, why would you not want to use it yourself?
09:06 < roconnor> aj: If you think adding BIP8(true) to Bitcoin Core is never acceptable then I suppose "bip8(false,3m)+bip8(true,1y)" was not what you were arguing for.
09:07 < aj> roconnor: i don't think that
09:07 < roconnor> oh
09:08 < roconnor> oh by non-starter you mean we shouldn't start with that.
09:08 < roconnor> rather that we should never do that?
09:08 < aj> roconnor: modern soft fork activation and dec-thresh approaches both presume "lockinontimeout=true" (or equivalent) gets set as the default behaviour a year or so after the initial deployment attempt fails to succeed, provided it still reaches very large support
09:09 < aj> ah, i mis-spoke. "i think bip8(true,anything) going into core ***in an initial deployment attempt*** ought to be a non-starter" is what i should have said
09:10 < roconnor> oh okay.  While I disagree, I think that is a reasonable position.
09:10 < aj> i don't see how we can measure community support for activation to justify unconditional lockin without having tried a deployment first. maybe my imagination is lacking
09:11 < harding> I strongly agree with: "i don't see how we can measure community support for activation to justify unconditional lockin without having tried a deployment first"
09:13 < zmnscpxj__> So basically we are going with Modern Software Activation?
09:13 < roconnor> I personally think if we reach out in good faith to everyone who particpates, and we endevour to make taproot has harmless as possible, and we get no reasonable object, then it is safe to do a BIP8(true) inital deployment.
09:13 < zmnscpxj__> I agree with roconnor
09:14 < roconnor> But I'd rather start with BIP8(false) than debate starting with BIP8(true) for 3 months. :)
09:14 < zmnscpxj__> how soon can we get a BIP8-false? And what is timeout? 3months?
09:14 < aj> roconnor: "we reach out", "we endeavour", "we get no reasonable objection" -- the "we" in there sounds very centralised and powerful and responsible to me
09:15 < zmnscpxj__> what pronoun do we use for a decentralized entity?
09:15 < aj> "everyone" ?
09:16 < roconnor> I'm still failing to see how "bip8(false,3m)+bip8(true,1y)-after-community-support-is-observed" is in any way better than "bip8(false,2y)+forced-activation-after-community-support-is-observed" beyond harding's observation that we get a version bit back a little quicker in case we abort activation of tarpoot.
09:16 < zmnscpxj__> I personally think if everyone reaches out in good faith to everyone who participates, and everyone endeavours to make taproot as harmless as possible, and everyone gets no reasonable objection, then it is safe to do BIP8(true) initial deployment
09:17 < aj> roconnor: convince matt that 2 years is long enough. convince luke that 2 years isn't too long. get back to me in less than three months?
09:17 < roconnor> I personally think if everone reachs out in good faith to everyone who particpates, and everyone endevours to make taproot has harmless as possible, and no one get no reasonable object, then it is safe to do a BIP8(true) inital deployment.
09:18 < aj> roconnor: there are plenty of bitcoiners who haven't paid any particular attentioned to taproot, they won't be doing any reaching out
09:18 < harding> I think it's important to many Bitcoin Core contributors that we not be seen as dictating consensus changes, not even if every contributor believes ever Bitcoin user wants them (or will tolerate them).
09:20 < zmnscpxj__> what actual actions are performed or opposed?
09:23 -!- roconnor [~roconnor@host-45-58-208-39.dyn.295.ca] has quit [Ping timeout: 256 seconds]
09:24 -!- roconnor_ [~roconnor@host-192.252-163-181.dyn.295.ca] has joined ##taproot-activation
09:25 -!- roconnor_ [~roconnor@host-192.252-163-181.dyn.295.ca] has quit [Client Quit]
09:26 -!- roconnor_ [~roconnor@host-192.252-163-181.dyn.295.ca] has joined ##taproot-activation
09:26 -!- roconnor_ [~roconnor@host-192.252-163-181.dyn.295.ca] has quit [Client Quit]
09:27 -!- roconnor [~roconnor@host-192.252-163-181.dyn.295.ca] has joined ##taproot-activation
09:27 < aj> roconnor: irc(false,30seconds) not recommended, i guess?
09:28 < roconnor> I don't know. I get disconnect I end up back as roconnor_, but all sorts of channels won't let me change names to roconnor because roconnor_ is muted for being unregistered.
09:30 < aj> hmm, i msg nickserv "identify aj password" and "ghost aj" when i lose my nick and afaik it works fine fwiw
09:30 < roconnor> and when I log out of freenode I cannot change my nick in Konversation to roconnor because I'm not logged in.  But when I'm logged in I cannot change my nick either.
09:31 < roconnor> so I just restarted Konversation.  Maybe I need a better client.
09:31 < roconnor> oh can you identify aj when you are not currently aj?
09:31 < aj> yeah, you just have to specify the nick i think
09:32 < roconnor> That may have never occured to me.
09:32 < aj> otherwise you couldn't ghost people who steal your nick while you're offline
09:32 < roconnor> I'll try to keep that in mind for next time.
09:35 -!- _joerodgers [~joerodger@c-76-125-83-191.hsd1.ar.comcast.net] has joined ##taproot-activation
09:35 < aj> roconnor: so i think there's a few reasons things might not activate quickly: (a) miners just don't upgrade quickly no matter what; (b) malicious miners who want to harm bitcoin have >5% hashpower and think delaying/preventing activation harms bitcoin; (c) pro-bitcoin miners have short-term interest in delaying activation (cheaper coins in the short term, same value in the long term?); and during
09:35 < aj> a deployment attempt we might get info on (1) how dedicate miners are to opposing -- do we need a UASF or is there 80% of hashpower that can do bip91 again and that's enough? (2) how interested are users, will it take 5 years for everyone to upgrade or 5 months?
09:36 < roconnor> So I think "bip8(false,2y-4y)+forced-activation-after-community-support-is-observed" would be the activation method with the most widespread support.  I'm not sure if aj was arguing that starting with BIP8(false,3m) might be better or is better.
09:38 < aj> roconnor: (b) or (c) or (1) might motivate different techniques for forcing activation -- bip91, or a simple deadline, or something where support has some reward, or something where they have to pay a cost to oppose; and (2) in particular might give an indication that a very different timeframe is appropriate
09:38 -!- joerodgers [joerodgers@gateway/vpn/mullvad/joerodgers/x-62861712] has quit [Ping timeout: 240 seconds]
09:39 < roconnor> aj: I think all those things you say are true and support a BIP(--, 4 years) depolyment.
09:39 < roconnor> *initial deployment.
09:40 < aj> roconnor: i don't think you'll convince luke of that
09:41 < zmnscpxj__> you might if it is BIP8(true, 4y) and promise that a shorter UASF will come anyway...?
09:41 < aj> zmnscpxj__: i don't think you'll convince suhas of that
09:41 < zmnscpxj__> hmmmm
09:42 < roconnor> I can try to convince luke that a BIP(--, 4 years) initial depolyment is good because it supports users performing a USAF if that is their will by forcing activation of that bit.
09:45 < roconnor> AFAIU luke just wants users to to a USAF and users running BIP(--, 4 years) gives much more taproot enforcement support when USAF is successful.
09:46 < roconnor> And if luke truly things that USAF is what got segwit activated and it was the mark of a whole successful deployment procedure, I'd like to argue that the existing base of BIP9(segwit) users was a foundation in that success.
09:47 < zmnscpxj__> I think luke considers that BIP8(true, *) *is* UASF; he simply argues that users want the feature yesterday and will prefer a BIP8(true, 3months).  But I could be wrong and it would be best to get luke-jr
09:48 < roconnor> zmnscpxj__: my understanding is that luke doesn't want activation enforce in Bitcoin Core.
09:48 < zmnscpxj__> hmmmm
09:48 < zmnscpxj__> not certain
09:50 < roconnor> And, at least as far as the first deployment goes, neither aj nor harding would want BIP8(true) in Bitcoin Core either.
09:50 < zmnscpxj__> okay
09:50 < zmnscpxj__> I think I can get behind some kind of BIP8(false, *) then
09:51 < zmnscpxj__> with a plan to deploy a BIP8(true, *) later
09:52 < aj> roconnor: "UASF" not "USAF", totally different types of enforcement... :)
09:52 < roconnor> oops.
09:52 < zmnscpxj__> fairly common mistake
09:56 < aj> roconnor: maybe "flag day softfork" (with or without "mandatory signalling") is better language. to me, the "user-activated" part of UASF means that it should be an "opt-in flag day" on users' behalf, rather than the default they get next time they upgrade, at least until it's clear that everyone's opt-ing in
09:57 < roconnor> aj: In what context?  (I think I agree with you).
09:58 < aj> roconnor: better than "UASF". i initially just meant "harder to typo"
09:58 < zmnscpxj__> FDS "flag day softfork"
09:58 < zmnscpxj__> Which should be easier to type on QWERTY keyboards
09:59 < aj> FDSF vs SFFD then san fran fire dept
09:59 < zmnscpxj__> oh no
09:59 < zmnscpxj__> FDSF vs FSF even
10:00 < roconnor> aj: I mean I think I would agree that the UA) in UASF means that users have to explicity run a modified version of Bitcoin Core or update a configuration file at least.  Something that I think is a bad idea, which is why I avoid using UASF, but something I think luke thinks is a good idea, which is why I would use UASF to describe his perfered activation method.
10:02 < roconnor> (Ultimately all users decide whether or not to run Bitcoin Core and what version, but apparently everyone seems to like to make a big deal about what Bitcoin Core choose to merge or not to merge)
10:03 < harding> roconnor: I think it's a big deal because many of us want people to continue to run Bitcoin Core, even if they have the ability not to.
10:06 < aj> harding: and that bitcoin core nodes should (be able to) enforce the new rules as soon as they are activated
10:06 < roconnor> harding: Are developers merging code into Bitcoin Core because it is will maintain or increase the number of users of the software, or are developers merging code into Bitcoin Core because they believe it makes Bitcoin Core better and they hope users agree.
10:10 < harding> roconnor: I suspect different people have different goals for their contributions.
10:34 -!- brg444 [uid207215@gateway/web/irccloud.com/x-ufeyungvvjpkpzbb] has joined ##taproot-activation
11:10 < harding> Here's a rough draft of the document discussed earlier: https://gist.github.com/harding/dda66f5fd00611c0890bdfa70e28152d  ; I still need to go back and add links and references, plus go through the logs to see what other notable variations were discussed, plus edit/proofread the whole document, but I think it's a start.  At this point, suggestions on other pros/cons to add (or objections to the existing ones) would be
11:10 < harding> especially useful.
11:10 < harding> Oh, and I need to pandoc it to wikitext and actually add it to the wiki, of course.
11:16 < michaelfolkson> This is a very useful summary, thanks
11:27 < jonatack> Fantastic harding
11:28 < felixweis> harding MVP
11:32 < jonatack> roconnor: can only speak for myself: goal of reviewing and proposing code in Bitcoin Core is to make Bitcoin better (robust, decentralised, private, features, UI/better/easier to use, etc.) and hope that users agree (your second suggestion), hopefully naturally leading increasing adoption of the software (your first suggestion)
11:32 < jonatack> *leading to
11:38 < luke-jr> roconnor: UASF is fundamentally the natural state of any softfork, until some activation condition triggered by a third party is defined
12:05 < michaelfolkson> You think that because it was how the previous soft fork was activated? Or because it is superior? Or both?
12:15 < michaelfolkson> I think I am still (!) a touch confused on what happened when SegWit activated. It activated because there was a threat of a UASF soft fork right? What percentage of full nodes were signaling for it
12:18 < belcher_> michaelfolkson the important metric is how much of the economy signalled for it, rather than _number_ of nodes
12:18 < belcher_> err, not signalled.... more like supported
12:18 < harding> Was willing to reject payments that paid non-UASF bitcoins.
12:19 < michaelfolkson> Any good write ups or stats?
12:19 < michaelfolkson> Or was it just a hazy threat that was never quantified?
12:19 < waxwing> there were also some futures markets. and the litecoin activation event/incident/shenanigans. and all kinds of stuff. obviously it is impossible for it to be objectively quantified, not least because people can lie.
12:19 < harding> I think luke-jr ran a poll that required respondents link their Coinbase account (as an anti-sybil measure).  Maybe he has a link to those results.
12:19 < belcher_> this site has a list of businesses https://web.archive.org/web/20180827154339/http://www.uasf.co/
12:19 < waxwing> futures markets are kind of good.
12:20 < harding> I know there were S2F future markets, but I don't recall any UASF futures.
12:20 < harding> S2X
12:21 < waxwing> yeah sorry you're rigth, that's what i meant. but i have a vague sense there was *something* like that earlier in the year.
12:21 < belcher_> iv got some links here which aim to convince that the UASF movement really did cause segwit to activate https://gist.github.com/chris-belcher/a8155df5051bb3e3aa96#the-uasf-caused-segwit-activation
12:21 < belcher_> we can never know for sure of course
12:22 < harding> I think there were some people who were making "bets", e.g. I think someone offered a million dollar bet with Ver.  I think Ethan Heilman and co-authors published a paper about how they could've done that bet trustlessly.
12:22 < michaelfolkson> Yeah I am not arguing that there wasn't support for it. But it wasn't a UASF right? It was a miner activated fork under the threat of a UASF?
12:22 < michaelfolkson> Thanks for the link belcher
12:23 < michaelfolkson> *belcher_
12:24 < michaelfolkson> And that was definitely preferable to a UASF playing out
12:26 < waxwing> the miners fulfilled the requirement of bip91 iirc. do you consider it would only be UASF if there was a minority hashpower fork which later became majority?
12:26 < waxwing> i mean UASF is kinda just an idea isn't it? :)
12:26 < belcher_> the threat of a doing a thing is as powerful as the thing itself
12:26 < waxwing> technically everything is a UASF. and nothing is :)
12:27 < belcher_> so like how LN channel are only secure because of the threat of a punishment transaction
12:27 < waxwing> bitcoin is a UASF of fiat currency
12:28 < michaelfolkson> "UASF is fundamentally the natural state of any softfork" I'm trying to understand this statement. Absolute chaos is the natural state of any soft fork?
12:28 < belcher_> maybe he means all consensus rules are ultimately enforced by users
12:29 < waxwing> yeah, and that's what my quips above meant.
12:32 < michaelfolkson> I am taking away from this that UASFs are chaos and should absolutely avoided unless miners leave users with no choice. The absolute worst case scenario of any softfork
12:33 < michaelfolkson> But if that is incorrect I would happily be corrected :)
12:33 < belcher_> i think the thing you're concerned about isnt UASF (as all soft forks are UASFs) but soft forks which lead to a chain split
12:34 < belcher_> the bip66 soft fork was actually miner-activated and lead to a chain split, which was nearly a disaster, but that was because of code bugs rather than BIP148-style coordinating
12:37 < michaelfolkson> All soft forks are actually activated by miners because miners cannot be sybilled. But they are activated under the instruction of users. The miners pull the final handle under threat of the users. If they refuse there is chaos
12:37 < luke-jr> michaelfolkson: that UASF is the natural state of softforks is an objective observation of how Bitcoin works in general
12:37 < luke-jr> michaelfolkson: it's not a value judgement, mind you
12:37 < luke-jr> michaelfolkson: Segwit was activated *by* a UASF; nodes signals were irrelevant
12:37 < belcher_> All soft forks are actually activated by miners because miners cannot be sybilled. <----- that doesnt follow, and is also incorrect
12:38 < luke-jr> here's the current KYCPoll data: https://luke.dashjr.org/programs/kycpoll/answers.php
12:38 < luke-jr> I think Coinbase broke the API so it probably froze at some point
12:38 < belcher_> in bitcoin, all consensus rules and changes to those rules (either hard forks or soft forks) are enforced by users who use full nodes to accept bitcoin as payment... if you're looking for sybil resistance they also have that, because localbitcoins, bitrefill, coinbase.com, etc cant be sybiled
12:40 < luke-jr> michaelfolkson: there is no real involvement of miners in a softfork, unless the softfork explicitly enables them to activate it
12:40 < luke-jr> belcher_ said it better
12:41 < belcher_> a hard part technically with activating a consensus rule change is that all the users have to change their rules *at the same time*, and previously that was done by having miners coordinate it, but it can also be done by having the rule change happen on a certain datetime (which is how bip148 worked)
12:41 < michaelfolkson> Right but it is a Mexican standoff. The users might prefer one chain but fear the consensus is the other chain. The miners might prefer the other chain but fear the consensus is the other chain
12:41 < luke-jr> the users are the consensus
12:41 < belcher_> no theres no mexican standoff, because miners and users do different things
12:41 < belcher_> users define what the coin is, miners define the history of transactions of that coin
12:42 < belcher_> its not a "balance of powers" or anything like that, instead they have different jobs
12:42 < michaelfolkson> The users are watching what everyone else is doing. They are watching what the miners (and the exchanges do)
12:42 < belcher_> exchanges are included in "users" here
12:43 < michaelfolkson> If I'm a user I am going to care and monitor what the miners do. Unless I can sit back, not make any transactions and wait to see what the winning chain is. The miners don't have that luxury
12:44 < luke-jr> users don't need to care what the miners do
12:44 < luke-jr> if miners violate the rules, they're mining an altcoin
12:44 < michaelfolkson> But as a user I might not know what the consensus rules are
12:44 < waxwing> miners qua miners have no involvement in consensus rule setting. miners *as users* do, but in that sense you can forget that they are miners.
12:44 < luke-jr> then you're not a user
12:44 < belcher_> michaelfolkson in this discussion "user" just means "anybody who uses a full node to accept bitcoin as payment", note that this is a much narrower definition of the word "user"
12:44 < luke-jr> users DECIDE what the consensus rules are
12:45 < michaelfolkson> Ok I'm not a user :)
12:45 < belcher_> so if a person stops transacting then they arent a user
12:45 < belcher_> yes
12:45 < michaelfolkson> Or a poorly informed user at least
12:45 < luke-jr> belcher_: well, some users have the ability to transact
12:45 < luke-jr> belcher_: it's not as simple as dismissing those users
12:46 < michaelfolkson> During chaos I would like to see what everyone is doing including the miners
12:46 < luke-jr> eg, random Joe could dump on some bogus chain that gives him coins
12:46 < michaelfolkson> I wouldn't be bold enough to completely ignore what the miners are doing
12:46 < michaelfolkson> I wouldn't be stupid enough to blindly follow them but I would monitor what they are doing
12:48 < belcher_> miners have it the other way, every hour their ASICs arent running can be millions of USD lost
12:48 < belcher_> they dont have the luxury of just stopping
12:48 < michaelfolkson> Yeah I think that is an important game theoretic element
12:48 < belcher_> a nice analogy is if all the gold miners got together and decided amongst themselves it would be cheaper and better if they mined copper instead
12:48 < belcher_> problem is, the people who actual buy gold will notice if they suddenly get sold copper bars
12:50 < belcher_> the analogy breaks down because gold miners dont have anything to do with the process of transacting gold... but its still a useful analogy
12:52 < michaelfolkson> Well and there are scientific definitions of what the elements of gold and copper are. Bitcoin is not defined precisely, consensus is not permanent definition
12:53 < belcher_> checking those definitions in this analogy is like using a full node wallet
12:53 < belcher_> when you have a bar you check its density, colour, conductivity, etc, etc
12:54 < michaelfolkson> Honestly if I am user and there is chaos on the consensus rules all I can do is look around and see what other people are doing
12:54 < belcher_> and when you get given a bitcoin transaction you check its formatted correctly, that the signature is valid, that no coins were created out of thin air (except by miners, and only under a strict schedule)
12:54 < michaelfolkson> If it is gold and copper I don't care what other people are doing. I do scientific measurements
12:55 < belcher_> you're talking about the network effect (checking what everyone else does)
12:55 < jeremyrubin> Small proposal: in order to aid the compatibility between different BIP8 suggestions, I propose that all BIP8's include a mandatory 1 year period after close where 100% signaling will activate the fork.
12:55 < belcher_> gold and copper have that too, they could stop being money... in fact gold did stop being money already
12:56 < belcher_> jeremyrubin isnt that equivalent of just making the close time 1 year later?
12:56 < jeremyrubin> That way, a future soft fork which locks something in that is compatible to a previous deploy on the same bit or a different bit can cause those older clients to upgrade.
12:56 < jeremyrubin> belcher_: no, because it requires 100%, which means it can no longer be effectively used as the primary upgrade path
12:56 < michaelfolkson> I can still exchange gold and copper for money (fiat, Bitcoin). No big deal. I know what they are scientifically and so does the person I sell them to
12:56 < jeremyrubin> Signaling intent that that BIP8 is dead, but it's left "hanging" just to not close off a potential upgrade path
12:56 < belcher_> michaelfolkson you can also exchange bcash for money (fiat, bitcoin) :p
12:56 < belcher_> or any other altcoin
12:57 < jeremyrubin> This becomes more apparent as it is disucssed using lower thresholds, e.g. 80%
12:57 < jeremyrubin> but even with 80%, the next period requires a 100% signaling in the next period.
12:57 < michaelfolkson> belcher_ I can but part of its value is claiming to be the real Bitcoin. I could never sell you copper claiming it is gold and charging you the price of gold
12:58 < belcher_> jeremyrubin right, so the close time is extended by 1 year, and that last year requires 100% signalling instead of 80% ?
12:58 < jeremyrubin> sure. The issue is that you might want your second deploy to have 2 periods of LOCKED_IN as opposed to just 1
12:58 < jeremyrubin> So that the old deploy (1 locked_ins) is compatible
12:59 < belcher_> michaelfolkson historically there were many attempts to pass off other stuff as "real gold", it was called alchemy and chemistry was invented because of it
12:59 < belcher_> the analogy isnt even that bad the more i think about it
12:59 < jeremyrubin> The reason to do this is that people are proposing things like BIP8 3 mos false which I think is just sort of weird by default given that it's a free option to allow those clients to be compatible if desired
13:00 < luke-jr> IMO first we need to fix BIP8 to support varying timeoutheights
13:00 < luke-jr> right now I'm pretty sure it breaks outside of two identical variants with only lockinontimeout differing
13:02 < jeremyrubin> varying timeoutheights?
13:02 < jeremyrubin> luke-jr: I think this is what I'm trying to express is that this helps handle varying parameter sets compatibly
13:34 < roconnor> harding: the Gently discourage apathay has an Issue discovered solution of soft-forking a repair or soft-forking out a tapleaf or soft-forking out taproot.
13:35 < roconnor> and also a commit to accellerated activation.
13:42 < roconnor> harding: the BIP8(false) schemes might need a pro: * makes it look like developers are not deciding the consensus ruls.
13:42 < roconnor> I'm pretty cyncial, so you might want to phrase that in a nicer way.
13:43 < jeremyrubin> s/look like/abundantly clear/ for future would be coercers
13:44 < roconnor> I'll let you guys phase it since it is your critera. :)
13:45 < roconnor> I'm of the opinion is it simply not possible for developers to decide the rules of Bitcoin under any circumstances because developer cannot for users to download and run software.
13:45 < roconnor> *cannot force
13:49 < roconnor> (and to a lesser extent I believe that even entertaining the idea that developers need to go through special efforts to ensure they are not seen as dictators of Bitcoin rules simply plays into the false narative that Bitcoin developers have this power which they simply do not have to begin with.)
13:49 < roconnor> That'd said, let's git taproot activated. :)
13:50 < jeremyrubin> git activate taproot
13:50 < roconnor> and if BIP8(false) is what it takes, then I'm on board.
13:50 < jeremyrubin> git: 'activate' is not a git command. See 'git --help'.
13:50 < roconnor> sudo git activate taproot
13:51 < jeremyrubin> roconnor: we should propose more forks so that some of them fail, making it clear we do not have that power
13:51 < jeremyrubin> bitcoin2xCoins release incoming
13:54 < jeremyrubin> it's a good point though, the conduct makes it seem like we actually do have this control and don't want to be seen a way v.s. just trying to reflect the truth
14:04 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined ##taproot-activation
15:33 -!- fiatjaf [~fiatjaf@177.205.197.19.dynamic.adsl.gvt.net.br] has quit [Ping timeout: 265 seconds]
15:49 -!- TechMiX [~TechMiX@ti0169q161-1541.bb.online.no] has quit [Quit: Leaving.]
15:49 -!- TechMiX [~TechMiX@ti0169q161-1541.bb.online.no] has joined ##taproot-activation
17:52 < zmnscpxj__> "makes it absolutely clear developers are not deciding the consensus rules" seems to imply "developers accept the statement 'every softfork is a UASF'"
18:09 -!- slivera [~slivera@103.231.88.10] has joined ##taproot-activation
18:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
19:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
19:03 -!- fiatjaf [~fiatjaf@2804:7f2:2a83:3b59:ea40:f2ff:fe85:d2dc] has joined ##taproot-activation
19:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
19:15 < aj> developers having control is an equilibrium condition, and one that most other coins are in. sure, at one level it's only possible because users of those coins are willing to accept that equilibrium rather than dumping all the coins, but that's not a very practical distinction
19:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
19:51 -!- mol [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
19:53 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
20:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
20:16 -!- slivera [~slivera@103.231.88.10] has quit [Ping timeout: 264 seconds]
22:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
22:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
22:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
23:10 -!- real_or_random [~real_or_r@2a02:c207:3002:7468::1] has quit [Ping timeout: 260 seconds]
23:39 < luke-jr> developers having control is one reason why we shouldn't be trying to convince everyone to use a single release ;)
23:40 < cato_> has someone started collecting proposals (with pros/cons) yet?
--- Log closed Mon Jul 20 00:00:26 2020