--- Log opened Sat Mar 06 00:00:48 2021
00:05 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
00:07 -!- cguida [~cguida@2806:2f0:51c1:5cee:5aed:6fc2:e93a:5ee0] has joined ##taproot-activation
00:08 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds]
00:28 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
00:28 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
00:51 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
00:52 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds]
01:15 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
01:32 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
01:33 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
01:41 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
01:41 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
01:46 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
01:46 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
01:49 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds]
01:58 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
01:58 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
02:10 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
02:10 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
02:25 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds]
02:39 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
02:44 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 245 seconds]
02:56 -!- jonatack [~jon@37.171.4.192] has joined ##taproot-activation
03:24 -!- eoin [332541ae@51.37.65.174] has joined ##taproot-activation
03:58 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has quit [Ping timeout: 265 seconds]
04:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:16 -!- belcher_ is now known as belcher
04:23 -!- eoin [332541ae@51.37.65.174] has quit [Quit: Connection closed]
04:39 < harding> aj: https://github.com/bitcoin/bitcoin/pull/21377 wow, thanks!
05:47 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
05:50 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
06:13 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
06:27 -!- lightlike [~lightlike@p200300c7ef40f60000393d6829769396.dip0.t-ipconnect.de] has joined ##taproot-activation
06:35 -!- eoin [332541ae@51.37.65.174] has joined ##taproot-activation
06:50 -!- eoin [332541ae@51.37.65.174] has quit [Quit: Connection closed]
08:21 -!- commmon [~common@unaffiliated/common] has quit [Quit: Leaving]
08:24 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
08:31 -!- eoin [332541ae@51.37.65.174] has joined ##taproot-activation
08:44 -!- common [~common@unaffiliated/common] has joined ##taproot-activation
08:46 < eoin> When are the meetings held here?
08:47 < belcher> they were on an ad-hoc basis... it wasnt a regulra thing eoin
08:48 < belcher> someone would post on the mailing list saying "they'll be a meeting at <date> <time>" and then it happened (twice so far iirc)
09:05 -!- jonatack_ [~jon@37.171.4.192] has joined ##taproot-activation
09:07 -!- jonatack [~jon@37.171.4.192] has quit [Ping timeout: 260 seconds]
09:31 -!- sanketcell [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Ping timeout: 246 seconds]
09:31 -!- sanket1729_ [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Ping timeout: 260 seconds]
09:39 <@michaelfolkson> I do think people trying to hold onto BIP 9 is a bit dumb at this stage. If this "speedy trial" proposal can't be fitted into a more flexible template of BIP 8 then we will need a new BIP.
09:40 <@michaelfolkson> It makes no sense to include LOT or MUST_SIGNAL in a new BIP if a new BIP is what is needed
09:40 -!- eoin [332541ae@51.37.65.174] has quit [Quit: Connection closed]
09:42 < roconnor> I beleive aj would say that modifying the existing code in Core to add a minimum activation time is *even simplier* than the BIP8-height modifications.  And it is so very easy that look I've already made such a PR.
09:42 -!- eoin [332541ae@51.37.65.174] has joined ##taproot-activation
09:43 <@michaelfolkson> I'd need to think about it (and see what Luke etc thinks) on whether it makes sense to try to include this in a more flexible BIP 8 or whether we need a new BIP
09:43 <@michaelfolkson> roconner: You think new BIP?
09:43 <@michaelfolkson> roconnor *
09:44 < roconnor> um... it sort of depends on whether these sorts of changes to Bitcoin Core require a BIP to be merged.
09:46 <@michaelfolkson> I was thinking it fits into the BIP 8 template but it doesn't. References to BIP 9 are nonsense though
09:46 <@michaelfolkson> I think either would be fine. A new BIP probably makes more sense, thinking about it
09:47 < roconnor> Well, I think BIP 8 ought to have an activation height parameter added to it.
09:47 <@michaelfolkson> Hmm interesting
09:47 < roconnor> And if we end up not merging BIP8-height we should maybe modify BIP9 to add a activation time field.
09:48 <@michaelfolkson> What's the point on BIP 9 if we're not using it?
09:48 <@michaelfolkson> I mean sure if the BIP 9 author wants to merge it, then no harm I suppose
09:48 < roconnor> I mean if we wind up in a position where BIP8-height never gets merged, then we are using BIP9 I guess.
09:49 < roconnor> or maybe I'm missing something technical here.
09:51 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##taproot-activation
09:51 < achow101> I assumed am did bip9 because that's already in core. height based with bip 8 would require more review
09:52 < achow101> i'll do the bip 8 version on monday
09:53 < roconnor> achow101: how do you feel about my recommendation of building BIP8-height on aj's PR?
09:53 -!- lightlike [~lightlike@p200300c7ef40f60000393d6829769396.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
09:53 < achow101> roconnor: I haven't looked at it in detail yet so I don't know if that would be any easier
09:54 < roconnor> right. that is fair.
09:54 < achow101> although I'll probably take his timings (rounded to nearest retarget heights)
09:54 <@michaelfolkson> I think there is general agreement on height being superior option
09:54 <@michaelfolkson> (could be wrong on that though)
09:55 < roconnor> his PR doesn't have activation parameters.
09:55 < achow101> oh
09:55 < roconnor> I'm pretty sure of that. Let me double check.
09:55 < aj> roconnor: i think the activation method needs to be described in a bip, but that could be a paragraph in bip-341, provided the logic is simple enough
09:55 < achow101> michaelfolkson: I think that is the case, but I'm pretty sure aj's pr was the simplest "least dependency" implementation
09:56 < achow101> rather than saying bip 9 is superior
09:56 < aj> achow101: that was the goal, yes
09:56 < aj> roconnor: yeah, i stripped params out of the PR and just put them in the mailing list post
09:57 < roconnor> right.
09:58 < achow101> briefly looked at the pr, and my main comment is that it feels like we should be parameterizing things like threshold to be on a per-deployment basis instead of globally
09:58 < achow101> but that's more work :)
09:58 < aj> achow101: versionbits code is a pain to try and do that stuff
09:59 < achow101> yeah, I've noticed
09:59 < aj> achow101: bip-91 implementation hacked it on. i have some refactoring code to clean it up, but refactoring consensus code...
10:00 < achow101> so instead we can do it with bip 8 implementation, and do it correctly the first time
10:00 <@michaelfolkson> Rusty (a co-author of BIP 9) agreed it was dead. At least in BIP terms I think we make BIP 8 more flexible or we make a new BIP. I think either is fine. But code is more important than BIP considerations
10:00 < aj> the current bip8 code doesn't try cleaning very much up
10:01 < achow101> aj: I foresee this to be one of those prs where I end up rewriting it when I try to build on top
10:01 < aj> (and cleanups are annoying to backport to 0.21 which we ought to do for taproot activation)
10:02 < roconnor> ouch backporting.
10:02 < aj> (#21337 is built off the branch point, so should merge cleanly on both master and 0.21 already)
10:03 < aj> bip8 code's also built from that point, but i think recent merges broke bip8 from merging on to master :(
10:03 < achow101> well that would suck
10:04 < roconnor> maybe we can rebase master on bip8 :D
10:07 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 264 seconds]
10:11 -!- jonatack_ [~jon@37.171.4.192] has quit [Quit: jonatack_]
10:11 -!- jonatack [~jon@37.171.4.192] has joined ##taproot-activation
10:14 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
10:26 < luke-jr> BIP 8 as-is has never been used, so adapting it makes more sense than yet another BIP
10:31 <@michaelfolkson> luke-jr: Maybe. The thing is though I'm happy with BIP 8 as is assuming we go with "Speedy trial" and it fails. I think it will be what we go straight to if "Speedy trial" fails
10:32 <@michaelfolkson> BIP 8 as is is optimal for a longer activation period e.g. 1 year
10:33 <@michaelfolkson> It can't be avoided though. We need a more flexible BIP 8 or a new BIP.
10:34 <@michaelfolkson> I'm actually leaning towards new BIP now even though originally I thought that was a dumb idea
10:34 <@michaelfolkson> The state transition diagram etc gets complicated otherwise https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#state-transitions
10:34 < achow101> istm we can just add more parameters to bip 8
10:35 <@michaelfolkson> I don't want this to slow code progress as that is the most important thing. Any BIP changes can come afterwards (assuming we have consensus)
10:36 <@michaelfolkson> But the sooner we can stop referring to BIP 9 the better, that just complicates things
10:39 < luke-jr> istm?
10:39 <@michaelfolkson> ?
10:39 <@michaelfolkson> It seems to me
10:41 < midnight> Huh. I always thought it was "I seem to 'member'
10:41 < luke-jr> lol
10:42 < luke-jr> no consensus on acronym :P
10:42 < midnight> kinda works
10:42 < midnight> :-)
10:43 <@michaelfolkson> We have our first opposition to "Speedy trial"
10:43 < luke-jr> sigh
10:43 <@michaelfolkson> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018596.html
10:44 < achow101> it sounds like his concern is with those who were adamant about lot=true
10:44 < achow101> his concerns can be assuaded if someone from that group responds with support of Speedy Trial
10:45 < achow101> *probably
10:45 < luke-jr> achow101: S.T. is only okay as a way to preempt LOT=True, not a substitute
10:45 <@michaelfolkson> I ACK "Speedy trial". Should I make this clear on the mailing list? Should others? I don't want to clog up mailing list but I also don't want people getting wrong impression on the level of support so far
10:45 < luke-jr> preempt and grow support for*
10:46 < achow101> luke-jr: sure, but I think matt's concern is that the lot=true group will try to organize a uasf during Speedy Trial
10:46 < luke-jr> lolwut
10:46 < achow101> at least that's my reading of his email
10:46 < luke-jr> that'd be crazy
10:46 <@michaelfolkson> Yeah that would
10:46 < luke-jr> assuming you mean mandatory signal for the S.T.
10:47 < luke-jr> obviously organizing LOT=True to follow it still proceeds, yes
10:47 <@michaelfolkson> If "Speedy trial" fails LOT=true is on table. But if it succeeds it isn't needed for Taproot
10:47 < luke-jr> even for S.T. it makes sense to do an independent release with both ST+LOT=True
10:48 < achow101> it sounds like he means organizing for mandatory signaling during ST
10:48 < luke-jr> (but not overlapping)
10:48 < luke-jr> I don't know how anyone would seriously think that's a possibility
10:48 < achow101> (could just be an interpretation error, english is hard)
10:48 < luke-jr> I mean, if ST began in 3 months, maybe a risk, but if it begins now and ends in 3 months..
10:48 < luke-jr> what if we just do a 2-period window?
10:48 < luke-jr> 1 month
10:49 < luke-jr> I think that still works out the same?
10:49 < achow101> I think that's too whort. that could jsut fail because signaling miners were unlucky?
10:50 < luke-jr> hmm
10:50 < achow101> In all deployments, I basically just consider the first period to be useless due to upgrade time anyways
10:50 < luke-jr> well, it's just a speed-trial anyway
10:50 < luke-jr> it's okay if it fails :P
10:51 < luke-jr> 3 periods? first one to try, second to realise an issue occurred and address it, and a final to give a second go?
10:51 < achow101> it's not really a trial if you give it low chances of success...
10:51 < luke-jr> sure it is, that's half the point
10:52 -!- eoin [332541ae@51.37.65.174] has quit [Quit: Connection closed]
10:52 < waxwing> it does seem like a very strange objection.
10:52 < AaronvanW> I definitely think Matt's concerned about putting together a LOT=true effort within that three month speedy trial window, and yes I think a confirmation from luke and/or michael that that won't happen might go a long way. (but I'm not sure about that last part, ofc.)
10:53 < luke-jr> AaronvanW: neither of us can speak for everyone
10:53 < AaronvanW> I know
10:53 < waxwing> 'start later' - but these mysterious people who would campaign to do a different activation can do so during the delay?
10:53 <@michaelfolkson> Right, seconded. I can't control a single person
10:53 < AaronvanW> luke-jr but you can speak for yourself
10:53 < luke-jr> AaronvanW: which means little
10:53 < luke-jr> if it were up to me, LOT=True would be live on the network today
10:55 <@michaelfolkson> Personally I don't want to respond because I can't say anything of use and arguments are just going to get heels to dig in again for no reason
10:56 <@michaelfolkson> I can say I don't support a UASF during ST. I can say I support ST. Apart from that..
10:56 < achow101> that's fine
10:56 < AaronvanW> luke-jr: you just said in this chat "that'd be crazy". if you'd explain why, that could go a long way too. (again, not asking you to speak for others.)
10:57 < achow101> I think we just need to indicate that there is support for ST from people from all groups
11:09 <@michaelfolkson> Anyone have instructions for responding to a mail when you've only got it in your digest and haven't received it? Do you need to use the Message ID? Or just respond to the person ccing the dev list
11:09 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
11:09 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
11:09 <@michaelfolkson> (with Re: Subject title)
11:11 < luke-jr> IIRC the general thought is "don't use digests"
11:11 < jeremyrubin> [3/6/21 10:50] <achow101> In all deployments, I basically just consider the first period to be useless due to upgrade time anyways
11:11 < jeremyrubin> achow101: not really useless unless starttime = release date
11:12 -!- stortz [b1982408@177.152.36.8] has joined ##taproot-activation
11:12 <@michaelfolkson> luke-jr: Ok, thanks. Good to know
11:12 < jeremyrubin> I think a good way to think of starttime < relative 2 months as a "well if people upgrade fast enough why not collect signals"
11:12 < jeremyrubin> opportunistic
11:13 < roconnor> Matt's hypothetical group of Reckless-UASF, ones willing to activate in a 3 month window simply does not exist.  If that's the NACK he wants to bring to a PR, then I'm probably willing to take my chances in Core review.
11:13 < jeremyrubin> but I expect the latter month -- especially in a ST scenario -- to be more relevant for activation (and not because of urgency to get it in)
11:14 < jeremyrubin> so i think shortening ST to like 1 period or 2 periods seems... silly
11:14 < roconnor> In particular, I'm pessimistic that Matt's flag day PR would pass Core review as it runs up against the "devs don't decide the rules" faction.
11:14 < roconnor> And if both PRs are nacked then Core does nothing and we do get the chain split risk that Matt is so worried about.
11:15 < jeremyrubin> 6 appears to me to be a relatively realistic parameter selection, where fewer periods there's real risk of not activating given timelines being too short, and more periods would just be meaning that there are actual reasons not to activate taproot
11:22 < luke-jr> roconnor: "Core does nothing" does not imply a chain split, and would in fact be an okay outcome
11:22 < luke-jr> maybe even a more ideal outcome than ST ;)
11:54 -!- eoin [332541ae@51.37.65.174] has joined ##taproot-activation
11:56 -!- eoin [332541ae@51.37.65.174] has quit [Client Quit]
11:59 <@michaelfolkson> I've responded on the mailing list, hopefully I did it right. The key point being all of Matt's proposals suffer from chain split risk in the face of an alternative competing, incompatible activation mechanism. If that's his only criticism of ST we are golden
12:01 <@michaelfolkson> That's what so great about BIP 8. You could have a LOT=true running with a LOT=false for a year (minus two weeks) until the final two weeks when they are incompatible.
12:09 < stortz> ST is start time?
12:09 < achow101> Speedy Trial
12:16 < stortz> https://github.com/bitcoin/bitcoin/pull/21377
12:17 < stortz> this?
12:19 <@michaelfolkson> That is the first PR opened attempting to start implementing it stortz
12:22 <@michaelfolkson> Details are here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html
12:24 < stortz> ok
12:27 <@michaelfolkson> Ok for anyone who hasn't responded on the mailing list, if you support ST can you respond to harding's original email. I want it to be clear on the mailing list how much support this has (or doesn't have if the case may be)
12:28 <@michaelfolkson> I know this will clog up the mailing list for a day but I'm getting worried that an individual or two will try to unpick this to death too
12:33 <@michaelfolkson> That includes you too please luke-jr if you don't mind
12:36 < harding> Maybe just create a gist that people can comment on?
12:36 < harding> (I assume most people with informed opinions will have a GitHub account already.)
12:43 <@michaelfolkson> Ok worth a try: https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f
12:43 < harding> michaelfolkson: thanks!
12:45 <@michaelfolkson> Announcement: If you support ST (Speedy Trial) proposal please ACK this so we can log the level of support for this proposal https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f
12:56 < stortz> I've read matt's response to ST twice and I still don't understand what problem he sees in it
12:56 < stortz> maybe I'm just stupid
12:58 < stortz> he thinks 3 months is long enough to organize a bandwagon around ST in a "join or die" type deal?
12:59 < AaronvanW> stortz: the idea behind ST is that is either activates within a short window, or otherwise expires so something else can be tried. matt's concern is that users won't allow it to expire, and instead try to activate it by running a BIP148-style UASF client that mandates signaling by the end of the three month window. does that make sense?
12:59 < stortz> yes I think I get it
12:59 <@michaelfolkson> Whatever is chosen someone can unpick it. I don't think this is a great attempt at unpicking it as it applies to literally every single activation mechanism
13:00 <@michaelfolkson> You could have a UASF within a day
13:00 <@michaelfolkson> In that case the argument is to release a 1 day ST tomorrow
13:01 < stortz> I like the idea of ST
13:02 < AaronvanW> stortz: more specifically, i think his concern is that a small group of users will try... too small to succeed, but too big to cause chain-splits/re-orgs/etc.
13:03 < stortz> and folkson is right, that the concern applies to almost every activation method
13:03 < AaronvanW> *but big enough to cause chain-splits/re-orgs/etc.
13:04 < aj> michaelfolkson: it'd probably be more helpful if you were saying organising a UASF within a day was a crazy thing to try, rather than talking about how plausible it is...
13:06 <@michaelfolkson> aj: It would be crazy thing to try. As would responding to that threat by doing a 1 day ST. We've well passed the point of any of this not being crazy
13:06 < AaronvanW> I still think the best way to limit risk is through futures markets. it worked miracles for the 2X event. I suspect it might work even better for soft forks.
13:07 < AaronvanW> Paul Sztorc gave a talk about that at the first Scaling Bitcoin btw.
13:07 <@michaelfolkson> Before you set up your futures market can you ACK this please AaronvanW? https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f
13:07 <@michaelfolkson> Assuming you support ST
13:08 <@michaelfolkson> (or if you don't)
13:08 < stortz> aaron, do you have a gist or something explaining this futures market limiting risks
13:08 < AaronvanW> I don't have a github account
13:08 < stortz> I'd like to read on it
13:08 < stortz> about*
13:08 <@michaelfolkson> It doesn't take long to set one up
13:10 < stortz> "ACK or die" !
13:10  * stortz is joking
13:11 < achow101> luke-jr: is it acceptable for 19573 to need a small patch in order for the 0.21 backport?
13:11 < achow101> The main conflict I'm seeing is to the rename
13:12 < achow101> I believe all of the other conflicts can be resolved in a way that both master and 0.21 will like
13:13 -!- Ironhelix [~x@154.6.28.69] has joined ##taproot-activation
13:16 < Ironhelix> Hi everyone, I am dissatisfied with the increase in security of Taproot. It just seems like a half-step toward privacy to me, and getting another change down the road could be more contentious as bitcoin heats up.
13:16 < stortz> w h a t
13:16 < Ironhelix> Why do it if it doesn't really provide the privacy of competing options? Multisignature is nice, but it's like 5 years ahead of anywhere who isn't a non-hodler is going to even understand
13:17 < achow101> Ironhelix: there's more to taproot than just privacy.
13:17 < stortz> ##taproot-bip-review
13:17 < Ironhelix> thx
13:17 < Ironhelix> Yeah, taproot is huge
13:17 <@michaelfolkson> Thanks stortz, yes ##taproot-bip-review please Ironhelix
13:20 < achow101> luke-jr: actually it can be backported cleanly with the inclusion of a single additional commit in that backport
13:22 <@michaelfolkson> Can you ACK or NACK this aj? Thanks https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f
13:24 < aj> michaelfolkson: i'm not comfortable doing either of those for now
13:24 <@michaelfolkson> aj: Ok no problem. Thanks for letting me know
13:25 < belcher> aj why? are you just undecided or do you have concerns about it
13:26 < aj> belcher: i'd prefer to stay uncommitted?
13:26 <@michaelfolkson> That's fine, uncommitted is fine
13:26 < aj> belcher: or i'd rather see consensus develop rather than try to push it too much? not sure
13:27 <@michaelfolkson> belcher: aj has opened two effectively competing Core PRs ( flag day and ST)
13:28 < AaronvanW> yeah same for me I think. so far I haven't really ACKed anything or NACKed anything, I think I prefer to keep it that way. (I could probably live with every proposal I've seen so far, as long as it reaches rough consensus, or would at least be convinced that it wouldn't end badly.)
13:28 < belcher> i know, the reason i ask if that a big part of the opposition to 1y LOT=true is "well people dont have consensus about it", so if someone didnt like speedy trial i would have liked to figure out why and if it can be fixed... but yeah being non-commital if fine ofc
13:32 -!- jonatack_ [~jon@37.166.245.162] has joined ##taproot-activation
13:33 <@michaelfolkson> There was never going to be an option which was literally every single person's first preference
13:33 <@michaelfolkson> As long as non-committal people don't NACK it I think we are fine
13:33 < AaronvanW> stortz: so let's say the LOT=true UASF proceeds. exchanges could then list "split futures" for "LOT=true coin" and "LOT=false coin". people can trade these coins. if LOT=true coin becomes more valueable, that's info for miners that they better mine on the LOT=true chain, which in turn means that would be the only chain. If LOT=false coin becomes more valueable, miners will probably mine on the LOT=false chain, which m
13:33 < AaronvanW> eans LOT=true will be a minority chain, and given that info UASF proponents might just give up (or at least know that they'll probably be a minority coin).
13:35 <@michaelfolkson> AaronvanW: This is a futures market on a chain split. Not a futures market on whether LOT=true or LOT=false "wins"
13:35 < AaronvanW> a futures market on a potential chain split.
13:35 < belcher> yeah if the chain split doesnt happen the two futures are worth the same, usually
13:35 -!- jonatack [~jon@37.171.4.192] has quit [Ping timeout: 265 seconds]
13:36 < AaronvanW> if you bet on a chain (lot=false) that ends up not existing, you just just lose your money. as happened with 2X.
13:36 < aj> michaelfolkson: it's both; if one wins, the other token's price goes to zero. if there's a split, both tokens get exchanged for coins on the resulting chains
13:36 < belcher> right, one goes to zero
13:36 <@michaelfolkson> AaronvanW: The likely scenario is the case that miners activate under LOT=true, under LOT=false or on a network of both LOT=true and LOT=false
13:36 <@michaelfolkson> Highly likely even with 90 percent of mining pool support
13:37 < AaronvanW> that's fine.
13:37 < AaronvanW> you can bet on that :)
13:38 < mol_> :D
13:38 <@michaelfolkson> In 2017 at least SegWit2x coin was 10-20 percent of the value of Bitcoin. In this scenario, the probability of a chain split is tiny and then within that chain split you have 2,3,4 options
13:39 <@michaelfolkson> We could have a bet whether there is a chain split, yes we could. I wouldn't bet on that personally given I am trying to stop that from happening
13:40 < harding> michaelfolkson: the more you bet on chain_split_happens, the more incentive you create for other people to make it not happen.  :-)
13:40 < AaronvanW> yep
13:40 < mol_> and that's how you get people to be informed, get it?
13:41 < harding> I'd personally worry that a betting market would create a lot of skewed incentives.  You might believe x but say y so that you can bet on x more cheaply.
13:42 < AaronvanW> harding: so?
13:42 < AaronvanW> btw betting markets can't be stopped.
13:42 <@michaelfolkson> Yeah I've got no problem with a betting market existing, I just wouldn't participate in it
13:43 < aj> what if there were a betting market that you could bet on via lightning with signet coins?? what then?
13:44 < jeremyrubin> I have code for the ability to generate contracts where if Taproot fails to activate by a certain deadline you lose your coins
13:44 < harding> AaronvanW: I'm not saying that they should be stopped.  I am saying that they have problems.  The main problem I see with a lot of PS's proposals is that he applies the results from external market beting to situations involving insider betting without accounting for the the dollar betting problem.
13:44 <@michaelfolkson> aj: Hmm are the Signet coins still worth zero?
13:44 < jeremyrubin> It can work on a single date or on a recurring calnedar (e.g., every signalling period)
13:45 < aj> jeremyrubin: send to a taproot address with a locktime?
13:45 < jeremyrubin> 1 sec I'll pastebin the code and example here
13:45 < aj> michaelfolkson: there's a public faucet that afaik isn't empty
13:46 < AaronvanW> btw I found paul's blog post about fork futures: https://www.truthcoin.info/blog/fork-futures/
13:46 <@michaelfolkson> Anyone betting for a chain split is essentially betting against all the successful Bitcoin businesses, Bitcoin whales, Bitcoin investments etc
13:46 <@michaelfolkson> Good luck with that in 2021. 2017 was your opportunity
13:46 < stortz> AaronvanW I think I understand it
13:47 < roasbeef> FTX lists a buncha random event markets as is, they'd prob easily list any variant of what's been described here
13:48 < roasbeef> michaelfolkson: it's more about being able to sample sentiment w/ a market signal
13:48 < roasbeef> consider is complementary to miner signalling
13:48 < AaronvanW> harding: didn't mean to apply you said they should be stopped. yes that sounds like it might be a legitimate concern.
13:49 <@michaelfolkson> roasbeef: Yeah agreed. I'm just saying the probability of a chain split would today be very, very low. Even with all the shenanigans so far
13:49 <@michaelfolkson> roasbeef: I think the more interesting bet is Taproot being activated or not within a certain time period
13:50 < AaronvanW> michaelfolkson: sounds like you would bet on LOT=false coin then :) (Do you understand that having a futures market like this doesn't mean there needs to be an actual coin split?)
13:50 < AaronvanW> uhh no you would bet on LOT=true coin
13:50 < roasbeef> yeh formulate it however you want, it's just another signal to sample broad stakehodlers, you can't sample things like the number of nodes running a particualr version easily
13:50 <@michaelfolkson> roasbeef: Again I wouldn't participate in that betting market
13:51 < aj> AaronvanW: active-by-$height coin, which is independent of lot=true/false for most heights
13:51 < roasbeef> michaelfolkson: that's fine lol
13:52 < AaronvanW> aj: right, that's also interesting, but not what I was thinking of.
13:52 < jeremyrubin> aj: sorry, my connection died
13:52 < jeremyrubin> https://pastebin.com/gLTFqCPQ
13:52 < jeremyrubin> This works with Sapio, and the contract functions correctly today w/o CTV (as you can see in the JSON) since it is using a CTV signature based emulator, which happens to work 100% correctly/without tradeoff for the given application
13:53 < aj> jeremyrubin: huh, cute
13:54 < harding> jeremyrubin: "signature based emulator" just means presigned txes?
13:54 < jeremyrubin> not exactly -- do you have Sapio access? I can send you the documentation for the emulator server
13:54 < jeremyrubin> In this case, yes, you do presigned txns
13:55 < harding> Don't have access, have too much to do today to look, just wanted to make sure I understood the basic principle.
13:55 < jeremyrubin> this is a special case though where, because miners are in control of execution, there's no difference in trust model
13:56 < jeremyrubin> e.g., you could provide another presigned txn if you wanted, but miners would not mine it unless it was better for them
13:56 < jeremyrubin> So the presigned can be completely local in this case
13:56 < jeremyrubin> More generally the code can be configured to use an arbitrary federation of your choice
13:56 < jeremyrubin> (but irrelevant for discussion here)
13:59 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined ##taproot-activation
14:00 < belcher> hi BlueMatt
14:00 < BlueMatt> michaelfolkson: I need to run, I have a job outside of debating taproot activation, but, frankly, the idea that you have to join a particular irc channel live in order to have an opinion on a proposed change to bitcoin's consensus both insulting and a pretty good indication that anything that comes out of such a place be ignored.
14:01 <@michaelfolkson> BlueMatt: Your opinion has been read and digested on the mailing list BlueMatt. But discussion on parameters lends itself to a discussion rather than a back and forth via email
14:02 < BlueMatt> We've *always* had discussion on any parts of a fork activation on the mailing list. For many years (and prior to that forums).
14:02 < BlueMatt> also, sadly, I have a ton of work to do for my regular day job, which has prevented me from contributing any more than about a half hour every other day.
14:02 <@michaelfolkson> Personally I'm happy to go to whatever media you use (mailing list, podcast appearances, Twitter) and then coming back to IRC with your views
14:02 < BlueMatt> that should not, never has, and never should, imly that my opinion should be ignored.
14:03 < BlueMatt> including on particular parameters.
14:03 < harding> BlueMatt: I think michaelfolkson's "come out of the woodwork" comment on the ML may have been poorly phrased, but please don't use that as an excuse to shit on the good work being done here.
14:03 <@michaelfolkson> I've transcribed your TFTC podcast too
14:03 < roasbeef> w/e is said here will prob end up being summarized elsewhere, this is just a fast moving scratch pad
14:03 < harding> ^that
14:04 <@michaelfolkson> I couldn't have done any more to bring your views into the discussion here
14:04 < BlueMatt> anyway, gotta run.
14:04 < roasbeef> IRC is more conducive to iteration/generation of ideas, when they become more solified I've usually seen them posted elsewhere for closer examination
14:04 < jeremyrubin> +1 -- I also want to note that harding has done an excellent job collating discussions had over the last year that gives a solution that I think is closer to a globial optima than what was proposed with BIP8
14:04 < jeremyrubin> so I don't feel it's a brand new idea, rather it's actually incorporating tons of ideas on how to make safe consensus
14:04 < BlueMatt> michaelfolkson: I believe, and I may be wrong, that aside from my negative comments on forced-signaling, I attempted to keep podcast discussions to higher level things than advocating for a specific posision. given, indeed, the quick moving nature of the discussion.
14:05 < roasbeef> it's like ClubHouse....but text based (lol)
14:05 < BlueMatt> hehe
14:05  * jeremyrubin moves roasbeef to the audience
14:05 < mol_> BlueMatt, hi, take care
14:06 -!- hashcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has joined ##taproot-activation
14:10 < AaronvanW> harding: do you see a problem with insider trading in the context of fork futures specifically? I'd be interested to hear a concrete example.
14:11 < roasbeef> AaronvanW: who're the insiders in this case, pools/miners?
14:11 < AaronvanW> I don't know?
14:11 < roasbeef> yeh seems undefined, more participation means more market signal imo
14:11 < roconnor> I haven't read the scrollback, but I think I might suggest reviewing https://github.com/bitcoin/bitcoin/pull/21378 for Convert taproot to flag day activation
14:12 < roconnor> I'm totally in favour of this PR, but I'm pessamistic that it will pass Core review.
14:12 -!- hashcash is now known as h4shcash
14:12 < roconnor> and I think it would be helpful to establish that it won't if indeed it won't.
14:13 <@michaelfolkson> My preference would be ST and I think this is most likely to get consensus. But I'm not sure how to communicate that on a competing PR
14:13 < jeremyrubin> I just don't see the value in this V.S. BIP8 true nomando
14:13 < roconnor> well it isn't a competeing PR in a technical sense.
14:14 < jeremyrubin> (aside from seeing the value personally w/ a preference for known release dates)
14:14 <@michaelfolkson> roconnor: I'll light Concept NACK it if that is any way helpful
14:14 < jeremyrubin> (value w.r.t. getting consensus)
14:15 < h4shcash> jeremyrubin: +1 should use BIP8 LOT=false
14:15 < jeremyrubin> no I'm saying BIP8  LOT=true, mandatory_signal=false
14:15 < jeremyrubin> it's effectively a flag day with potential early activation
14:16 -!- maybehuman [b04a39a2@vpn23a.hotsplots.net] has joined ##taproot-activation
14:16 < jeremyrubin> which means if another movement picks up steam to signal there's not need to change clients
14:16 < h4shcash> my complaint is about not using height based activation
14:17 < jeremyrubin> Ah I see, yeah heigh based activation is better IMO
14:17 < jeremyrubin> i think the flag day AJ proposed is height based?
14:17 < h4shcash> jeremyrubin: i think it's bip9 unless something changed.
14:18 < jeremyrubin> h4shcash: AJ has two proposals
14:18 -!- maybehuman [b04a39a2@vpn23a.hotsplots.net] has quit [Client Quit]
14:18 < jeremyrubin> one is matt's flag day idea, one is the ST
14:18 < jeremyrubin> ST is currently BIP9 -- best to comment on GH about that (or I can note your preference)
14:18 < h4shcash> i'm thinking about about ST
14:18 < jeremyrubin> Matt's flag day is height based
14:19 < h4shcash> yes. ST should be height based. github linky?
14:19 < jeremyrubin> https://github.com/bitcoin/bitcoin/pull/21377
14:21 < jeremyrubin> aj: can I ask a basic question? Why can't we just make activation_time a height?
14:21 < jeremyrubin> I'm ok with starttime/stoptime being times
14:21 < jeremyrubin> (altho I pref having them heights longer term)
14:22 < h4shcash> jeremyrubin: lots of people saying height based in that too. good
14:22 < aj> jeremyrubin: hmm, would be annoying to test in the functional test suite maybe
14:22 < h4shcash> aj height based pls. bip8
14:22 < aj> jeremyrubin: no, i suppose height/times have a 1-1 mapping there, so that's probably fine
14:22 < roconnor> technically speaking both Flag day and Speedy Trial are combinable, and even if they weren't it would be okay to ACK both if you are happy with either.
14:22 < jeremyrubin> roconnor: flag day is idempotent with earlier signaling?
14:23 < jeremyrubin> But I don't like SPV mining
14:23 < jeremyrubin> so I think flag day should be released with early activation on signaling, if released at all
14:23 < roconnor> jeremyrubin: I mean, we can make activation a disjuction of multiple conditions.  I imagine it wouldn't be too hard.
14:24 < jeremyrubin> It seems that this is no different than bip8 LOT NoMando
14:25 < jeremyrubin> I don't get the hate for mandatory signalling personally -- I think SPV mining is worse
14:25 < jeremyrubin> but no need to rehash that I guess...
14:27 < roconnor> I mean the real question is whether flag day is acceptable or not.
14:27 < aj> what is "nomando" ?
14:27 < aj> oh no mandatory signalling?
14:27 < roconnor> no-manditory-signalling.
14:27 < jeremyrubin> nomando is fun to say/type
14:35 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has quit [Remote host closed the connection]
14:40 < harding> AaronvanW: the usual problem with insider betting is that you can usually make money more easily betting against what you know is right.  E.g., a prize fighter can either bet on himself (which may have a 30% to 70% of winning) or can bet against himself and throw the fight (which has a 99% chance of winning).  I think this would also apply to protocol development and I think it would be harmful to discussions like those occuring in this room
14:40 < harding>  if we had to spend a lot of our energy wondering who was working in good faith and who was taking a position only for a quick payout.
14:42 < AaronvanW> harding: I don't think a futures market should inform development, nor do I think many people would participate in such a market for reasons you just explained. (or if they do, that's their own risk.)
14:42 < harding> AaronvanW: how would you prevent developers from participating in a futures market?
14:42 < jeremyrubin> Personally I think if a futures market exists I would just torpedo the consensus change entirely
14:43 <@michaelfolkson> jeremyrubin: Noted
14:43 < AaronvanW> harding: I wouldn't. I don't think many bettors would participate.
14:43 < jeremyrubin> (I get that also represents an attack on development, but noting that any sort of liquid futures market that's not completely lop sided would indicate that we don't have consensus)
14:43 < harding> AaronvanW: that's probably true, but only because a lot of devs are too poor to bet.  :-)
14:44  * michaelfolkson gets out his SEC contact email address
14:44 < AaronvanW> jeremyrubin: I think a futures market would help a consensus change, if it's a non-contentious soft fork.
14:44 < jeremyrubin> AaronvanW: if the market isn't liquid, then it's not really a 'market'
14:44 < jeremyrubin> and it has 0 value in terms of a measure of sentiment
14:44 < AaronvanW> I don't think we're talking about the same thing.
14:44 < jeremyrubin> i suspect we are
14:45 < AaronvanW> I'm talking about a scenario where ##uasf proceeds with the UASF, so now there are two clients that could potentially cause a fork.
14:48 < AaronvanW> that's when the betting starts. it's not really about what devs will or won't do at that point.
14:54 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 264 seconds]
14:54 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
14:55 < jeremyrubin> my client crashed :/
14:56 < jeremyrubin> but anyways, I think that were that market thought to be likely to be liquid, it would show that people were uncertain of the outcome
14:56 <@michaelfolkson> You can't win with some people. Spend your days monitoring discussion, get criticized for not having a full time job. Don't spend your days monitoring discussion, get criticized for ignoring discussion on other forums other than a IRC channel
14:56 <@michaelfolkson> You. Cannot. Win.
14:58 < jeremyrubin> AaronvanW: prediction market on if a prediction market is liquid?
14:58 <@michaelfolkson> Open to suggestions on how you magically merge all global online discussions into one so you can take into account all voices
15:00 < jeremyrubin> michaelfolkson: are you advocating a prediction market on that basis?
15:00 < jeremyrubin> or just kvetching
15:00 < AaronvanW> jeremyrubin: if the market's not liquid that just means miners shouldn't take them too seriously. that's on them.
15:01 < jeremyrubin> if the market is liquid, we shouldn't be having any consensus changes
15:02 < harding> michaelfolkson: FWIW, I personally think the evolution of ideas should be individual → small private group (optional) → IRC (optional) → mailing list → BIP (optional) → PR → release → adoption (optional).
15:02 <@michaelfolkson> jeremyrubin: Ha. Open that prediction market on whether ST code ever gets merged. No there isn't a suggestion other than what I've been doing.
15:03 < jeremyrubin> harding: I think if we had a better funding market, I think that adoption (or the least, software that makes good use of a feature) should happen before release
15:04 < jeremyrubin> That no one has built anything *using* taproot is bad
15:04 < harding> jeremyrubin: "funding" market or futures market?
15:04 < AaronvanW> jeremyrubin: "if the market is liquid, we shouldn't be having any consensus changes" <- ??
15:04 < jeremyrubin> funding, e.g., for software clients doing something useful on signet
15:04 < harding> jeremyrubin: so adoption first on signet, then adoption on mainnet?
15:04 < roconnor> Indeed, I don't think this group really decides anything.  Merge decisions are made in PR.  Rather this discussion forum is, I think, mainly useful for helping in directing devlopers efforts.  For example...
15:04 < jeremyrubin> harding: yes we've waited too long for that with taproot i fear
15:05 < jeremyrubin> my hope with CTV is that I can more demonstratively show cool software that uses it before saying we should release it
15:05 < roconnor> Andy was planning on working on BIP8(1y,false) on Monday, and now AFAIU he will be working on ST instead.
15:05 < roconnor> Of course developers are free to do whatever interests them.
15:05 < jeremyrubin> it's a better proof that I've ironed out the kinks on it being useful
15:05 < harding> jeremyrubin: I've also tried to encourage people in that direction.  I think that's a problematic idea, though.  Everyone is busy with things that can be effective *now* that they don't want to spend much time on things that might work later.
15:06 < jeremyrubin> Yep -- it was navigating the straight of magellan to produce a code artifact that could be useful today with or without CTV
15:06 < harding> jeremyrubin: indeed, I seem to remember complaining about you moving CTV off of taproot precisely because I wanted people to be building things on taproot.  :-D
15:07 < jeremyrubin> harding: sadly it made sense for CTV to be non taproot for purely technical reasons
15:07 < harding> jeremyrubin: yes, I eventually accepted that argument.
15:07 < jeremyrubin> you save a bunch of bytes when you're using it for congestion control, which seemed relevant
15:08 < jeremyrubin> anyways -- digression
15:08 < jeremyrubin> Concretely, it would be great to see e.g. miniscript-taproot
15:08 < roconnor> sipa was working on taproot discriptors.
15:09 < roconnor> descriptors
15:09 < jeremyrubin> that would be a compelling artifact for me that would give me confidence that taproot isn't missing some piece of functioinality
15:09 < belcher> the problem isnt that people dont want taproot enough
15:09 < jeremyrubin> (for anyone reading along, this is not a taproot nack, just musing on harding's observation about the flow of upgrades)
15:10 < roconnor> There has also been work on musig descriptor/miniscript element.  Lots of discussion on issues related to sorting keys.
15:10 < jeremyrubin> belcher: I've felt that way at times -- I think people do *need* schnorr
15:10 < jeremyrubin> but the other components are nice-to-haves
15:11 < jeremyrubin> roconnor: that makes me feel worried FWIW
15:11 < roconnor> how so?
15:11 < jeremyrubin> if Taproot is introduced and sold on MuSig, we should know that it doesn't need changes for it to work
15:11 < roconnor> oh it doesn't need changes.
15:12 < roconnor> sorting vs unsorted keys is not a consensus change.  Both would work.
15:12 < roconnor> it's a mater of building a multisig protocol.
15:12 < roconnor> Do the participants have to order themselves?
15:13 < jeremyrubin> FWIW I agree that it shouldn't matter, but it's a more general point about if we're releasing consensus changes, we should actually have complete software that makes use of it
15:13 < roconnor> or do they sort themselves by pubkey
15:13 < jeremyrubin> E.g., if we had more people testing CSV i think we would have implemented it very differently
15:14 < roconnor> oh?
15:14 <@michaelfolkson> Can we move this to ##taproot-bip-review if it isn't activation related?
15:14 < jeremyrubin> <1 day> CSV <1 block> CSV should be spendable
15:15 < jeremyrubin> I don't think this is appropriate there either...
15:15 < jeremyrubin> but noted
15:15 < jeremyrubin> maybe wizards?
15:15 <@michaelfolkson> Yeah it is interesting but it isn't activation related
15:23 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has joined ##taproot-activation
15:27 < aj> jeremyrubin: "no one has built anything using taproot" --> https://github.com/jonasnick/taproot-ringsig is a counter example?
15:30 < jeremyrubin> aj: not entirely?
15:30 < jeremyrubin> I don't know why you'd want this?
15:31 < jeremyrubin> I would say that a counterexample would be Fidelity Bonds (which this claims something similar can be used for)
15:31 < harding> aj, jeremyrubin: maybe move to ##taproot-bip-review as michaelfolkson requested.
15:35 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Remote host closed the connection]
15:35 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has quit [Remote host closed the connection]
15:58 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 245 seconds]
16:01 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
16:26 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has left ##taproot-activation ["Ex-Chat"]
17:05 < luke-jr> achow101: the ideal is to not require a backport, just a clean merge of the same commit
17:06 < luke-jr> achow101: if that isn't possible, I'm not sure how important a clean backport is
17:06 -!- sanketcell [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##taproot-activation
17:06 < achow101> luke-jr: it's all clean merges
17:07 < luke-jr> achow101: eh?
17:07 < achow101> just need one more commit
17:07 < luke-jr> merge meaning the same commit hash
17:07 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##taproot-activation
17:08 < achow101> i'm confused
17:08 < luke-jr> achow101: it's not important, just a git nicety
17:08 < achow101> oh
17:08 < luke-jr> to be able to: git checkout master && git merge branchname && git checkout 0.21 && git merge branchname
17:09 < achow101> we've never had that requirement before
17:09 -!- jonatack_ [~jon@37.166.245.162] has quit [Read error: Connection reset by peer]
17:09 < luke-jr> achow101: it's not a requirement, just a nicety ;P
17:09 < luke-jr> one that is lost already I'm pretty sure
17:10 < luke-jr> (though it would be nice to have a policy in favour of it for bugfixes, but this isn't a bugfix anyway)
17:11 < achow101> well it's possible to have clean cherry-picks of your pr
17:12 < aj> luke-jr: hmm, think i've found a bug in the VersionBitsStatistics implementation :( should manage to exactly not matter for MUST_SIGNAL though, i think
17:13 < luke-jr> bleh
17:13 < luke-jr> VBS was never consensus before, was it?
17:14 < luke-jr> or is it used in the main vbits logic too?
17:15 < achow101> isn't VersionBitsStatistics only used for getblockchaininfo?
17:15 < aj> no, it wasn't consensus before
17:36 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
17:44 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed]
17:55 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds]
17:57 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
18:00 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 276 seconds]
18:01 < Emcy_> luke-jr are you supporting lot false now under a very short activation window?
18:09 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
18:09 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
18:10 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
18:11 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 264 seconds]
18:55 < luke-jr> Emcy: LOT=True needs to go on, but if folks want to preempt it with this trial thing, shrug
19:06 -!- belcher [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
19:06 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-activation
19:22 < cguida> I formally propose that we rename Speedy Trial to "Easy Activation" and "Hard Activation".
19:22 < cguida> "We can do this easy way, or we can do it the hard way"
19:23 < cguida> I think it communicates a bit better that there will be two activation periods, and that the first one is ideal
19:25 < AaronvanW> what is "hard activation" in this context?
19:26 < AaronvanW> if it's mandatory signaling, then I think LOT=true already embeds both. (year signaling, then mandatory.)
19:30 < cguida> "Hard Activation" is just what comes after Easy Activation. The hard portion is not well-defined; we just know that it will be more complicated and less certain.
19:31 < cguida> You're right that LOT=True already embeds both, but I think those opposed to it are correct in pointing out that there's a certain heavy-handedness about not trying LOT=False first.
19:32 < cguida> That's why I like the new name. It communicates that the Easy Way is a "cooperative activation", where everyone is moving in the same direction, of their own free will.
19:35 < cguida> Actually, that's an interesting question: if LOT=True already encapsulates "we can do this the easy way, or we can do it the hard way", then why is ST more popular? It does essentially the same thing
19:35 < AaronvanW> I think changing names now might be a bit confusing, but don't really care about the name otherwise.
19:35 < roconnor> Lots of different factions have lots of different views of the world, and what is and is not approprate for a bitcoin activation method.
19:36 < roconnor> ST is designed to be broadly acceptable to many different viewpoints for many different reasons.
19:36 < roconnor> and any individual viewpoint will easily point to another method that is superior to ST, but each one will point in a different direction.
19:37 < roconnor> but we don't need an activation code that is the best; because activation is trasient.
19:37 < roconnor> instead we need one that is widely considered acceptable by a diverse group of opinion.
19:41 < cguida> I've been thinking about the game theory of activation, and it strikes me that it can be seen as a sort of "iterated prisoners' dilemma", where if the parties cooperate everyone is better off, but if one party defects, then the other party gets screwed. The game can then be iterated as many times as needed, with each subsequent game incorporating the information gained from the previous iterations.
19:45 < cguida> I've heard that the optimal strategy in such an iterated game is to trust on the first iteration, then defect in reaction to what the other party did on the previous iteration
19:45 < cguida> that is, decide to defect or not to defect based on the previous iteration
19:47 -!- stortz [b1982408@177.152.36.8] has joined ##taproot-activation
19:47 < cguida> AaronVanW: People were saying that a catchy name might help with adoption. If it makes the difference between adoption or not, then I want the catchiest name :)
19:49 -!- rubikputer [~rubikpute@ip72-192-27-21.ri.ri.cox.net] has joined ##taproot-activation
19:50 < AaronvanW> cguida: yes I think you refer to tit-for-tat (re: iteration game). but who are the parties in this context?
19:52 < cguida> Yes, tit-for-tat, that's the name. Well, I suppose there are sort of broad, sort of fuzzy groups of players: the devs, the miners, the users, the exchanges, the apps
19:52 < cguida> the holders
19:53 < luke-jr> not sure this is comparable
19:54 < luke-jr> we have an activation that doesn't allow for [new] misbehaviour
19:55 < cguida> Are you referring to LOT=True?
19:57 < luke-jr> yes
19:58 < cguida> In that case, I think this is exactly comparable. In 2017, the choice was left to the miners whether to cooperate or not. They chose not to cooperate. This time people are on edge because the proper response to such bad faith behavior is to change strategies.
19:59 < luke-jr> a design flaw enabled the miners to sabotage in 2017; a well-designed system doesn't have such a flaw to begin with
19:59 < cguida> The "flaw" you're referring to is trusting the miners, correct?
20:01 < luke-jr> the flaw is giving miners the option to not-activate
20:01 < luke-jr> to cancel the activation
20:01 < cguida> Yes, exactly
20:01 < cguida> So yes, that is what you're sayinig
20:01 < cguida> saying*
20:02 < luke-jr> but it's not a "tat"; it's just a normal design
20:02 < luke-jr> even if the miners had always been well-behaved, the system shouldn't have flaws
20:03 < cguida> Are you saying bitcoin doesn't have flaws?
20:04 < AaronvanW> cguida: if LOT=true works like luke-jr thinks, there is no downside to users. (prisoners dilemma analogy suggests it shouldn't be optimal.)
20:04 < luke-jr> cguida: I'm saying we should avoid introducing flaws
20:05 < luke-jr> and fix flaws found
20:05 < luke-jr> in this case, we found the flaw the hard way
20:05 < luke-jr> and fixed it! it's silly to talk about adding it back in
20:06 < cguida> AaronvanW: luke-jr: is that an accurate representation of your views? That LOT=true carries no downside risk to users?
20:08 < luke-jr> cguida: I do not wish to make an absolute claim at this time. I do think of the options known, it is the least risky.
20:09 < cguida> luke-jr: ok
20:10 < cguida> AaronvanW: Why do you say the prisoners' dilemma analogy suggests LOT=true wouldn't be optimal?
20:11 < AaronvanW> sorry, I'll correct: if LOT=true works to upgrade succesfully, there is no downside to users.
20:12 < cguida> AaronvanW: isn't that true of all the activation proposals?
20:22 < AaronvanW> cguida: in a prisoners dilemma, the idea is that acting selfishly isn't optimal for all parties. I assumed you thought LOT=true would be users acting selfishly. but maybe you should make it more clear who you think the parties are. (right now I also think it doesn't apply in this context.)
20:31 < cguida> AaronvanW: Maybe it's a bad analogy, apologies if it is. In my mind, the miners are one party and the users/devs (and maybe everyone else?) are another party. The previous iteration of the game was in 2017, when the miners betrayed the trust that was given to them. So, the "tit-for-tat" strategy would indicate not trusting the miners this time
20:35 < nothingmuch> fwiw tit-for-tat is optimal for iterated prisoner's dilemma with an unknown number of iterations and when there's no accidental defection, tit-for-two-tats is optimal if such errors are tolerated
20:36 < nothingmuch> but in either case i don't think the analogy really holds because modeling different interest groups as individual players in a prisoners' dillema seems like an over-simplification
20:36 < cguida> AaronVanW: Or, you could see the taproot activation itself as a smaller version, where the ST proposal has two iterations of the game (or just one, if the miners cooperate). This strategy involves trusting the miners temporarily, which we should do if we think the bad actors from 2017 are no longer around. It definitely makes sense to trust the miners less than in 2017, but maybe we should give them a chance to redeem the
20:36 < cguida> lves, as it were, and extend the LOT=false olive branch.
20:37 < nothingmuch> also i think iteration implies the game is the same every time in the formal model
20:38 < nothingmuch> and i'm not even sure if "optimal" is correct, IIRC it those two strategies won in in simulation based competitions? is optimality proven?
20:39 < luke-jr> cguida: LOT=False doesn't do that
20:39 < luke-jr> cguida: it gives them a power they were never supposed to and shouldn't have, for no reason
20:43 < AaronvanW> nothingmuch: I think the best performing strategy actually had some random defections to "test the waters" and see if they could exploit.
20:43 < cguida> nothingmuch: cool, thanks for the details. yeah, the hard part of using such models is deciding how they relate to real-world situations. the current situation can definitely be interpreted as a prisoners' dilemma in multiple ways, or maybe it's not a great analogy
20:44 < cguida> luke-jr: if that's true, then why was bip9 used?
20:46 < rubikputer> cguida: I think taproot is different than segwit as there's nothing in taproot that stands to significantly reduce the fees that miners collect, in 2017 they had an incentive to do that but that isn't the case now
20:46 < cguida> AaronvanW: I've also heard that occasionally trusting again, even after defection, to see if the other party has changed, can be a winning strategy
20:46 < rubikputer> still makes sense not to trust them very much but I don't think we have to be as cautious as we are
20:47 < nothingmuch> cguida: that's tit-for-two-tats, it recovers from accidental defection
20:47 < AaronvanW> cguida: makes sense
20:48 < AaronvanW> oh
20:49 < nothingmuch> FWIW i'm also still not sure if the payoffs really map to a prisoners' dillema, clearly there's a positive payoff from cooperation, but i think all non-cooperative outcomes are roughly the same?
20:49 < cguida> rubikputer: i agree, this time is different. but, it's also the same in a lot of ways. It seems strange to me that people would support bip8(false) when bip9 is essentially the same, and that went pretty poorly last time
20:50 < cguida> at least, bip(8) false by itself
20:50 < cguida> bip8(false)* xD
20:55 < cguida> nothingmuch: seems like there should be ways of making the non-cooperative outcomes as painless as possible. People were talking about fork futures markets earlier. It seems obvious to me which fork would be more valuable
20:56 < nothingmuch> cguida: i mean specifically the asymmetry, if a defects but b cooperates, the payoff is positive for a, negative for b, but if both defect it's strongly negative for both
20:57 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 264 seconds]
20:58 < cguida> nothingmuch: Not necessarily. In 2017 things went pretty ok for the users and pretty not ok for the miners that defected
20:58 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
20:59 < nothingmuch> by defect do you mean bcash? or failing to activate?
20:59 < AaronvanW> cguida: I'd argue miners didn't defect in the end.
21:00 < AaronvanW> but again, that's why it might be helpful to specify how this maps onto a prisoners dilemma.
21:00 < nothingmuch> but either way the defining characteristic is that cooperation positive, unilateral defection is more positive than that for defector, and bilateral defection is very strongly negative for both
21:00 < nothingmuch> defining characteristic of prisoners' dilemma that is
21:01 < cguida> nothingmuch: could be either
21:02 < cguida> nothingmuch: i see what you mean, i think prisoners' dilemma is probably the wrong construct to use here
21:03 < cguida> That's why I called it "the easy way, or the hard way". The easy way is easy for everyone; the hard way is hard for everyone. There's gotta be some game theory about such a scenario
21:05 < AaronvanW> the game theory is that the easy way is easy for everyone... and that's it :)
21:05 < cguida> But I also think that in the case of taproot, rubikputer is correct that this time is different, since there's no organized opposition to taproot, so it seems to me that anyone opposing it will (eventually) lose
21:06 < rubikputer> is there actually any coherent argument *against* taproot?  at least on the surface level "just make the blocks bigger" sounds more straightforwards than trying to explain segwit to the layperson
21:09 < nothingmuch> afaik no, except fud. and re segwit - thinking about it more both the capacity increase and the fees seem more complex than "unfairly cheap", i think the only real payoff was covert asicboost
21:09 < cguida> rubikputer: not that i can think of. there was a troll on the mailing list complaining that it was "too private"
21:15 < luke-jr> cguida: BIP 9 was used because at the time we were ignorant of the bug
21:16 < cguida> nothingmuch: perhaps this is a better construct: https://en.wikipedia.org/wiki/Stag_hunt
21:18 < nothingmuch> cguida: yep, seems like it
21:20 < cguida> luke-jr: as in, nobody realized that the miners could just... not activate?
21:23 < stortz> 'stag hunt tolerance'
21:23 < stortz> this game theory idea if from 1755 damn
21:27 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed]
21:54 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 260 seconds]
22:00 -!- cguida [~cguida@2806:2f0:51c1:5cee:5aed:6fc2:e93a:5ee0] has left ##taproot-activation []
22:04 -!- cguida1 [~Adium@2806:2f0:51c1:5cee:2075:9321:d3a2:809] has joined ##taproot-activation
23:17 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
23:33 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
23:41 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
--- Log closed Sun Mar 07 00:00:49 2021