--- Log opened Tue Jul 14 00:00:20 2020
00:02 -!- jonatack [~jon@37.166.139.83] has joined ##taproot-activation
00:39 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
00:39 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
01:40 -!- jonatack_ [~jon@37.165.119.176] has joined ##taproot-activation
01:43 -!- jonatack_ [~jon@37.165.119.176] has quit [Read error: Connection reset by peer]
01:44 -!- jonatack [~jon@37.166.139.83] has quit [Ping timeout: 240 seconds]
01:52 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
01:53 -!- slivera [~slivera@103.231.88.10] has quit [Remote host closed the connection]
01:53 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
01:53 -!- slivera [~slivera@103.231.88.10] has joined ##taproot-activation
02:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
02:01 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
02:38 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined ##taproot-activation
02:40 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-activation
03:19 -!- schmidty [sid297174@gateway/web/irccloud.com/x-ckqifnzpczeptffn] has quit [Ping timeout: 244 seconds]
03:19 -!- schmidty [sid297174@gateway/web/irccloud.com/x-mhynivjgihtafjze] has joined ##taproot-activation
03:22 -!- amiti [sid373138@gateway/web/irccloud.com/x-xxenphispxqqcfhv] has quit [Ping timeout: 244 seconds]
03:24 -!- amiti [sid373138@gateway/web/irccloud.com/x-qhstazuxjuddhqrd] has joined ##taproot-activation
03:37 -!- TechMiX [~TechMiX@ti0169q161-1541.bb.online.no] has quit [Quit: Leaving.]
03:37 -!- TechMiX [~TechMiX@ti0169q161-1541.bb.online.no] has joined ##taproot-activation
03:52 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
03:56 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 258 seconds]
04:10 -!- TechMiX1 [~TechMiX@ti0169q161-1541.bb.online.no] has joined ##taproot-activation
04:10 -!- TechMiX [~TechMiX@ti0169q161-1541.bb.online.no] has quit [Read error: Connection reset by peer]
04:34 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Remote host closed the connection]
05:57 -!- visa [~textual@ool-68f67be8.dyn.optonline.net] has joined ##taproot-activation
05:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-activation
06:01 -!- jnewbery [~john@164.90.178.190] has joined ##taproot-activation
06:51 -!- slivera [~slivera@103.231.88.10] has quit [Remote host closed the connection]
07:06 -!- benthecarman [~benthecar@185.195.16.181] has joined ##taproot-activation
07:07 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
07:13 -!- joerodgers [Thunderbir@gateway/vpn/mullvad/joerodgers/x-62861712] has joined ##taproot-activation
07:29 -!- takinbo [~takinbo@unaffiliated/takinbo] has joined ##taproot-activation
07:46 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
07:58 -!- visa [~textual@ool-68f67be8.dyn.optonline.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
08:41 -!- brg444 [be2ec812@pc-18-200-46-190.cm.vtr.net] has joined ##taproot-activation
08:47 -!- alec is now known as cato_
08:54 < cato_> aj: I'm new so I guess this discussion was already brought up but in your ML post you mention that BIP8 includes an "optional mandatory activation at the end of the year."
08:54 < cato_> this implies that the decision of whether a soft fork becomes active is for practical purposes transferred to bitcoin core developers
08:58 < brg444> cato_ ultimately the impetus is on users to run the software. they could very well ignore it
08:59 < cato_> yes, but I think we can agree that this can look like core taking advantage of its "monopoly"
09:00 < cato_> I'm not saying it is, I'm just trying to understand all dynamics
09:01 < belcher_> lets remember that the group "core" was against the bip148 UASF yet it still happened
09:01 < belcher_> sorry i mean, "did not have consensus for", some core devs were for and some against, but the bip148 code was not added to core
09:02 < belcher_> so that can be an argument to why adding a soft fork to core doesnt necessarily mean the core devs control the consensus rules
09:02 < cato_> belcher_: thanks for the perspective
09:03 < belcher_> an added caveat is that the group "core developers" its quite a loose group, more or less anyone can join the meetings and start contributing
09:03 < cato_> how did signaling start in the past (let's avoid the segwit one for now because it was... different)
09:03 < cato_> core included the code for signaling and it was active by default?
09:03 < belcher_> yep
09:04 < cato_> okay, so that's still a LOT of soft power the reference software wields
09:04 < cato_> I don't think a last-resort mandatory activation should be part of the proposal right from the beginning. IMO it sends a wrong message, but I'm sure there's lots of arguments for doing so
09:05 < belcher_> i believe the OP_CSV soft fork used bip9, the OP_CLTV and BIP66 soft forks used the method of incrementing the version number, and very early soft forks by satoshi were done by pushing to the repository and not telling anyone
09:05 < belcher_> so bip9 and incrementing-the-version-number waited for the miners to signal readyness
09:05 < roconnor> Why would anyone be concerned about taproot activating?
09:06 < roconnor> Its just a matter of coordination rather than a referendum.
09:06 < belcher_> perhaps because of memories of trauma from the block size conflict
09:06 < cato_> roconnor: people have to touch a running system ;-)
09:07 < cato_> so I guess concerns this time would be technical instead of political
09:08 < belcher_> i think so yes
09:08 < roconnor> Argueably they never should have been political before either.  But ya, taproot seems far more of a technical change only.
09:08 < belcher_> with segwit there was lots of drama in the bitcoin space for over a year beforehand
09:09 < roconnor> It only touches segwit v1 spending, which currently is delibrately unusable.
09:09 < cato_> roconnor: but still, saying that no one should object is not a good reason to make the soft fork mandatory
09:09 < belcher_> id say the political environment is much more similar now to how it was before BIP66/OP_CSV/OP_CLTV, id guess most people just see it as a technical change not a political move
09:09 < belcher_> but i guess after segwit many people have the view of "we'll never let the miners stall again"
09:10 < roconnor> cato_: Certainly we want to solicit and hear objections that people have.  We did get some anonymous feedback posted to the ML earlier this year.  I think that was healthy.
09:10 < cato_> belcher_: yes, I think that's the reason why users might favor the mandatory activation
09:12 < cato_> effectively, miners would no longer be involved in any decision making. they can just speed up adoption
09:14 < cato_> the decision on activation is already made before signaling starts. and since, effectively, core decides when it starts, the discussion about starting the activation in core is the one that matters
09:14 < cato_> I don't see any problem with this approach. It's just not that obvious to first-timers like me
09:14 < belcher_> but then theres the argument that what if users actually dont adopt it either, then the soft fork gets activated but neither miners nor users enforce it
09:15 < belcher_> of course a reply to that is we think today most users will adopt it, and we've done outreach to the community
09:15 < brg444> how can that happen?
09:15 < belcher_> and a reply to that could be, well i dont know maybe they're lying or they'll change their mind
09:15 < roconnor> certainly now would be a good time for users to raise any concerns about the taproot design / implementation.
09:16 < cato_> belcher_: by user adoption you refer to running software that enforces the new rules, right? not actual use of the feature once it's available
09:16 < belcher_> yes cato_
09:17 < cato_> how is user adoption measured? using the client version string?
09:18 < belcher_> <brg444> how can that happen? <---- for example only 5% of miners and only 5% of users-by-economic-majority adopt the soft fork client, then bip8 activates after the timeout and someone skiddie hacker creates a tx which spends from a taproot script, and that causes a chain split with 90:10 ratio
09:18 < cato_> or can users signal using some bits in network messages as miners do in the block header?
09:18 < belcher_> cato_ not the client string, that can be easily faked (and was back when Bitcoin Unlimited was a thing)
09:18 < belcher_> ultimately because bitcoin aims to have good privacy we can never really measure user adoption well
09:18 < belcher_> the best we can do is go to lots of bitcoin merchants or other people who accept bitcoin as payment and ask them if they'll enforce the soft fork
09:19 < brg444> in this case the soft fork didn't activate... those users/miners just forked themselves off the network
09:19 < cato_> belcher_: yes, I also see why you mentioned they could lie
09:19 < cato_> even if you did collect some data, some actors might intentionally mislead
09:19 < belcher_> brg444 theres no "the" network, the 5% think they're on the real network and the 95% also think they're on the real network
09:19 < belcher_> (earlier i wrote the 90:10 ratio as a typo, it should've been 95:5)
09:20 < belcher_> cato_ but on the other hand they have no incentive to mislead, misleading basically means merchants lying to their customers and making their lives more difficult, for no benefit
09:20 < belcher_> when someone does this survey they're essentially asking "is this kind of money good here", so why would a merchant lie about that? they want to make sales dont they
09:20 < brg444> there is, as defined by the economic  in this scenario there would be no contention as to which chain is Bitcoin
09:24 < cato_> belcher_: ok, sounds reasonable. so whether core starts signaling takes such kind of information into account I guess
09:25 < cato_> and the rest is just a bunch of contributors going yay or nay, somehow weighted by their 'weight' in the community?
09:25 < belcher_> its pretty obvious to me that most economically-important users, at least in the english-speaking space im aware of, do want taproot
09:26 < cato_> belcher_: I totally agree that everyone with a good grasp of tx sizes and fees would want it. then again, when I look at the number of non-native multisig inputs and outputs compared to native segwit ones, I wonder... :-)
09:27 < belcher_> if the people making those non-segwit multisigs dont want to use taproot themselves then thats fine, as long as they dont actively oppose its activation
09:27 < belcher_> i bet most of the non-segwit multisig users are just busy and dont want to spend the time and risk on upgrading to segwit multisig
09:28 < cato_> belcher_: that's my assumption, too. maybe we'll see more adoption once fees increase to a point when saving a few weight units pays off
09:28 < belcher_> one important thing: if we end up in the 95:5 chain split situation i described earlier then suddenly everyone really does have to care, because they have to read bitcoin news portals to figure out whats happened and why did their tx just get reorged out and why did the price just drop, and what they should do
09:29 < cato_> but back to taproot activation. in a BIP-8-style scenario with mandatory activation, the decision to activate is essentially a yay-nay pool among contributions
09:29 < cato_> is that correct?
09:30 < belcher_> not really, the power is always with people who accept bitcoin as payment for something
09:30 < cato_> in theory, of course. but let's be practical for a moment
09:30 -!- MrHodl [ac625de3@gateway/web/cgi-irc/kiwiirc.com/ip.172.98.93.227] has joined ##taproot-activation
09:30 < belcher_> earlier in this channel someone mentioned there should be a page similar to this https://en.bitcoin.it/wiki/Segwit_support and this https://web.archive.org/web/20180827154339/http://www.uasf.co/ which tracks which economically-relevant actors will adopt the soft fork
09:31 < roconnor> The merge into Bitcoin core would presumably be done in the same way that everything else is merged into Bitcoin Core.
09:31 < belcher_> back in the bip148 times lots of people went around asking various businesses what they thought of bip148
09:31 < belcher_> (on that archive page scroll down to "What are companies saying about BIP148?")
09:34 -!- krvopije [~toni@185.106.109.144] has joined ##taproot-activation
09:34 < roconnor> As I understand, what went off the rails with segwit activation was simply the fact that segwit unknowningly interfered with a secret mining algorithm.  And there is no amount of discussion that is going to have the parties reveal secret mining algorithms.
09:34 < brg444> cato_ the mandatory setting is only a schelling point. it could be released with a user configurable option defaulting "=false" but then it becomes a coordination problem amongst user and can potentially create issues down the line. if the release default as "=true" then the user upgrading make a conscious decision to support that, if not enough
09:34 < brg444> people do so then the update fails
09:35 < belcher_> not only that roconnor , there was also the people who believed in on-chain scaling (i think they're stupid but they really seemed to genuinely believe in it)
09:36 -!- molz_ [~mol@unaffiliated/molly] has joined ##taproot-activation
09:37 < cato_> ok, so how many parties are involved in this? users, miners, companies (did I miss any?). ideally, you'd somehow measure support from all parties, and only go ahead with the fork if all agree
09:37 < cato_> problems are: you cannot objectively measure support for users and companies. that can only be done for miners
09:38 < roconnor> I think more than disagreement is needed.  There has to be some compelling argument against it.
09:38 < cato_> however, since segwit, we don't care about miners anymore, right. so yay or nay activation is anything but objective
09:38 < belcher_> when i say users i also include companies in that
09:38 < belcher_> i mean entities who accept bitcoin as payment for something (and therefore have the power to say "sorry your money is no good here")
09:39 < cato_> ok, then it's just users and miners
09:39 < MrHodl> Miners were also scared the privacy segwit would bring VIA LN.
09:40 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]
09:40 < MrHodl> If I'm not mistaken doesn't taproot improve privacy even further?
09:40 < belcher_> in some ways yes, but also note that stuff like my coinswap design doesnt require taproot
09:41 < belcher_> so for coinswap and the already-existing LN and coinjoin, is it not possible to stop bitcoin privacy by opposing taproot (or any soft fork)
09:41 < cato_> the thing about pre-segwit soft forks is they appeared "clean". hashrate is an objective measure of miner support. was user support considered in previous soft forks at all?
09:41 < roconnor> There is a fungability improvement around musig style multisig looking indistigishable from single signatures.
09:41 < cato_> or was it just made the center of attention when miners refused segwit?
09:41 < MrHodl> Doesn't taproot make CJ/CS less expensive?
09:42 < roconnor> I don't know if that counts as a privacy improvement, or is anything to be scared of.
09:42 < belcher_> cato_ right but be careful you dont fall into the "fallacy of the measurable", where you say "we can measure this, therefore its a useful thing to measure"
09:42 < belcher_> MrHodl not really
09:42 < cato_> belcher_: makes sense
09:43 < roconnor> taproot does make a lot of protocol cheaper by hiding unused script execution paths and allowing for more off-chain operations like adaptor signatures and musig.
09:43 < brg444> cato_ rough consensus does not require everyone to come to agreement or public support, only to consider disagreement
09:43 < cato_> but it seems weird that all pre-segwit soft forks were based on miner support
09:43 < roconnor> Most soft forks were flag days in the past.
09:43 < cato_> and all post-segwit soft works might be based on user support (by mandatory activation)
09:43 < MrHodl> cato_ : all?
09:44 < roconnor> well, many soft forks in the past were flag days.
09:44 < cato_> ok, my statement was apparently not correct. as someone only slightly paying attention it seemed that most pre-segwit soft forks were
09:45 < roconnor> The miner activation methods were not there to gauge "miner support"  It was a design for safe coordination.
09:45 < cato_> roconnor: wow! i complete misinterpreted that then
09:45 < roconnor> It was simply assumed that miners would support the new consensus rules, and it was just a matter of coordinating the miners to make the safest deployment possible.
09:46 < roconnor> because if almost all miners are upgraded, then it naturally protects any users that are late to the upgrade party.
09:46 < belcher_> is anyone aware of a bitcoin business which publicly said they support taproot itself (via a tweet or something)
09:48 < brg444> cato_ I wrote this some years back on the process of consensus building, I think it holds pretty well to this day https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
09:48 < roconnor> I personally don't see most of these soft forks, and especially taproot, and anything that is particularly controversial.  Again all we are doing is repurposing segwit v1 outputs, which are currently unused, and making them do something useful.
09:48 < cato_> brg444: thanks, I'll go through it
09:49 < jeremyrubin> roconnor: also in contrast to prior soft forks, v1 segwit was *designed* to allow for easy soft fork feature adding
09:49 < cato_> roconnor: yes, one would think Taproot is viewed positive by users and miners
09:49 < roconnor> And as much or more care has gone into the design and implemenation of taproot than any of the various other changes, such as wallet descriptors, etc., that Core developers do all the time without controversy.
09:50 < roconnor> So I don't see this proposed change as any more of a big deal than, say implementing HD wallets, or designing Bech32 addresses.
09:50 < roconnor> The only issue is that there is a coordination and upgrade step that needs to be solved.
09:50 < roconnor> that doesn't exist for non consensus changes.
09:51 < cato_> roconnor: so there should be no voting?
09:51 < roconnor> And we've had in the past the need for urgent Bitcoin software updates in the past to fix consensus errors.
09:51 < roconnor> So as long as we can coordinate better than that, we are doing pretty good :D
09:52 < roconnor> cato_: We definitely want to solict design feedback.  Taproot's script hash even got a very recent ammendment.
09:52 < cato_> or at least, no more explicit voting by miners. the go for taproot is implicit because there was plenty of discussion?
09:53 < MrHodl> roconnor: As long as miners/pools/exchanges understand that there are no privacy gains I don't see why there would be any contention.
09:53 < belcher_> im going to make a bitcoin wiki page which tracks which big businesses if any have expressed a view about taproot
09:54 < roconnor> We never intended to give miners a vote in the first place.  The BIP9 timeout was just a sort of natural design on what to do after a timeout.  The old style voting used to last forever, which seemd unreasonable.
09:54 < brg444> there was never a "vote" cato_
09:54 < brg444> belcher_ I think that's jumping the gun
09:54 < roconnor> When BIP9 was written no one expected miners to use the timeout to delibrately avoid activation.
09:54 < brg444> but you're free to do whatever you want
09:54 < cato_> brg444: ok
09:54 < belcher_> brg444 why?
09:54 < belcher_> (im not disagreeing i just want to know)
09:55 < jeremyrubin> (a lot of businesses don't want to publicly commit to something -- positive or negative --  to not be political)
09:55 < roconnor> AFAIU people did go around asking mining pools about Segwit support and AFAIU, everyone said ok go for it.
09:56 < brg444> I'm not at ease framing this in the way that segwit was. Those kind of support pages might have counter-productive result and invite contention because it suggests somehow that the issue may be controversial
09:56 < roconnor> Of course mining pools are not going to draw attention to their secret mining algorithm.
09:57 < roconnor> I don't think there was any way to avoid the segwit incident at the time, other than to have the foresight to realize that miners might abuse the BIP9 timeout to give them an effective veto.
09:57 < roconnor> which was never the intent of the timeout.
09:58 < jeremyrubin> roconnor: one can view UASF type things as an attempt to ship a bugfix to that
09:58 < roconnor> I think that is a fair view of the UASF proposal.  Though it never got merged into Core.
09:59 < jeremyrubin> Was there ever a PR for it?
10:00 < belcher_> yes
10:03 < jeremyrubin> https://github.com/bitcoin/bitcoin/pull/10417
10:03 -!- krvopije [~toni@185.106.109.144] has quit [Quit: Leaving]
10:05 -!- joerodgers [Thunderbir@gateway/vpn/mullvad/joerodgers/x-62861712] has quit [Quit: joerodgers]
10:07 < jeremyrubin> wumpus's close out comment is pretty reasonable summary I think https://github.com/bitcoin/bitcoin/pull/10417#issuecomment-302299372
10:07 < jeremyrubin> I don't think we've learned to work with custom builds since 17 tho
10:24 < brg444> i just condensed my article into a tweetstorm if you're interested cato_ https://twitter.com/bergealex4/status/1283086826002165760
10:26 < roconnor> I think that thinking about the process is a great viewpoint.
10:27 < roconnor> We should be thinking, who else do we need input from and how we can get their input.
10:27 < roconnor> And when we run out of people we can ask, then it is time to put it out there and see if it floats.
10:28 < brg444> yep. rough consensus should be objection based, not an attempt to lobby support all around
10:29 < jeremyrubin> not sure that's adversary robust
10:30 < jeremyrubin> i don't care to reach consensus with those whose goal it is to kill bitcoin
10:30 < brg444> fortunately no one suggested this
10:31 < jeremyrubin> objection based consensus fundamentally is that.
10:31 < jeremyrubin> its very easy to put out low grade objections and fud
10:31 < brg444> No. Read the thread
10:31 < brg444> or the article
10:32 < brg444> or this https://tools.ietf.org/html/rfc7282
10:32 -!- TechMiX1 [~TechMiX@ti0169q161-1541.bb.online.no] has quit [Read error: Connection reset by peer]
10:32 -!- TechMiX [~TechMiX@ti0169q161-1541.bb.online.no] has joined ##taproot-activation
10:32 < brg444> it's sufficient that objections are addressed if low grade or fud, but not accomodated
10:43 -!- joerodgers [~Thunderbi@141.98.255.150] has joined ##taproot-activation
10:43 < jeremyrubin> I think the difference is that there's more of a risk in Bitcoin that someone's end-goal is not a good outcome for Bitcoin. I think that risk is smaller in the IETF.
10:44 < gmaxwell> jeremyrubin: it absolutely happens in the IETF. But the IETF is also happy ignoring it.
10:45 < jeremyrubin> gmaxwell: yeah I don't think it doesn't happen, just that for Bitcoin there might be greater incentive for interference and disruption behavior. Or maybe the interference has happened in the IETF and that's why internet security sucks ;)
10:45 < gmaxwell> ericsson sent a bunch of people tro try to obstruct the standarization of Opus (RFC6716), but all they were allowed to do was slow things down a bit.
10:46 < cato_> brg444: very good article. My only regret is not coming across it earlier
10:46 < brg444> if someone's end goal is not a good outcome for Bitcoin it will most likely reflect in their objection and it will be evaluated accordingly
10:46 < gmaxwell> but you're right in some security contexts obstruction was more effective.
10:46 < brg444> yeah, stalling is an issue. ddos basically
10:46 < gmaxwell> But right the fact that people may have cross-motivations is why it's critical to demand objections me made in public and be specific.
10:47 < brg444> cato_ thank you!
10:47 -!- brg444 [be2ec812@pc-18-200-46-190.cm.vtr.net] has quit [Remote host closed the connection]
10:48 -!- brg444 [be2ec812@pc-18-200-46-190.cm.vtr.net] has joined ##taproot-activation
10:52 < jeremyrubin> Overall I just think that advocacy/championing/lobbying for a change -- despite drawbacks -- is better than just trying to wait around for all objections. In fact, lobbying is often better at drawing out criticisms because otherwise if you aren't a credible threat of getting consensus people can passively delay via apathy and 'other things to do right now'.
10:52 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
10:54 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
10:55 -!- MrHodl [ac625de3@gateway/web/cgi-irc/kiwiirc.com/ip.172.98.93.227] has quit [Ping timeout: 260 seconds]
10:57 < brg444> I think you're mostly arguing a strawman
10:58 < brg444> What I'm saying is that advocacy should be as simple as : "This is happening, here's how it works. do you have any objections?"
11:01 < brg444> What it shouldn't be is an attempt to draw up an exhaustive list of who supports and who doesn't and then make conclusions based on this
11:03 < schmidty> Outreach has the side benefit of developing relations as well. In fact this can even be seen as a primary benefit.
11:11 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
11:12 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
11:14 -!- emzy [~quassel@unaffiliated/emzy] has joined ##taproot-activation
11:21 -!- joerodgers [~Thunderbi@141.98.255.150] has quit [Quit: joerodgers]
11:22 -!- joerodgers [~joerodger@141.98.255.150] has joined ##taproot-activation
11:31 -!- joerodgers [~joerodger@141.98.255.150] has quit [Quit: Leaving]
11:31 -!- joerodgers [~joerodger@141.98.255.150] has joined ##taproot-activation
11:46 -!- TechMiX [~TechMiX@ti0169q161-1541.bb.online.no] has quit [Read error: Connection reset by peer]
11:47 -!- TechMiX [~TechMiX@ti0169q161-1541.bb.online.no] has joined ##taproot-activation
11:48 -!- brg444 [be2ec812@pc-18-200-46-190.cm.vtr.net] has quit [Remote host closed the connection]
11:48 -!- brg444 [be2ec812@pc-18-200-46-190.cm.vtr.net] has joined ##taproot-activation
11:51 < gmaxwell> brg444: one thing that might be okay which doesn't run afoul of your thinking is some action to show that among tech heads, support for taproot itself is unanimous.
11:51 < gmaxwell> e.g. which is a that the proposal is strong, rather than inviting controversy.
11:53 -!- joerodgers [~joerodger@141.98.255.150] has quit [Quit: Leaving]
11:53 -!- joerodgers [~joerodger@141.98.255.150] has joined ##taproot-activation
11:58 < brg444> sure. outreach is very different from petitioning people, which I what I think is premature. optech's work in that regard is crucial
11:58 < brg444> just making sure we avoid "are you with or against us" optics
12:00 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
12:00 < gmaxwell> it would be truly sad to see if taproot supporters manage to manufacture opposition,  by creating the false-- as far as we know-- impression that opposition already exists, or that its reasonable, and triggering people to join it.
12:00 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz]
12:02 < brg444> an effective way to help provide credibility to the proposal is to recapitulate the development process it went through and the notable changes/engineering decision that were taken. at least for me a list of name with yay or nay is a bit of an argument to authority and isnt a compelling argument
12:03 < gmaxwell> brg444: I think for a lot of people just knowing that a lot of people with relevant expertise support it is actually extremely useful information.
12:03 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined ##taproot-activation
12:04 < gmaxwell> Don't make a fallacy fallacy: "argument to authority" means 'this is right because an authoirty said so. period.'   while often when people reference authorities its really an argument  "This is right, and you can quickly see it, because if it weren't right these authorities probably wouldn't endorse it"
12:05 < gmaxwell> thats also why attacks on bitcoin weighed so heavily on falsely claiming that all the developers were blockstream, because it was an answer to why the relevant authorities would endorse something if it weren't okay (because they're not idependant and they have a conflict of interests).
12:05 < brg444> true
12:06 < gmaxwell> but really, again, I think were over thinking.
12:06 < gmaxwell> e.g. just having the project announce its being deployed is sufficient, let these imaginary opposing people speak up if they exist.
12:11 < brg444> indeed. i'm not opposed to tech people signing off. i'd think optech/core would suffice. just think we should avoid industry wide petitions for now
12:12 < gmaxwell> you could also do something after having tech people signing off is reach out to folks in industry and say "As of right now this is whats going to happen,  and I'm reaching out to find if you have any questions"
12:13 < gmaxwell> which can help head off someone lobbing a spurrious opposition based on a misunderstanding.
12:13 < gmaxwell> (e.g. because the ask the question and get it answered)
12:17 < gmaxwell> I guess a point I'd like to make is that when, in the interest of trying to appear super-fair you *falsely* express a lack of confidence in something you're confident in you're lying to people no less than if you fasely expressed confidence in something you're sure of,  worse, it sabotauges your own actions by stimulating your counterparties insecurities.  "oh, if people oppose this,... I
12:17 < gmaxwell> thought it was good, but do I really understand it *completely*? I probably should oppose it too".
12:17 < gmaxwell> People will sensibly hedge their neutral positions to opposed if they believe other people who know more are opposing. If there are actual opposition then it's something to be dealt with,  but imaginary opposition is the worst, because you can't even answer it.
12:25 < luke-jr> [16:14:12] <cato_> the decision on activation is already made before signaling starts. and since, effectively, core decides when it starts, the discussion about starting the activation in core is the one that matters <-- assuming Core releases an activation at all, which IMO we shouldn't
12:27 < luke-jr> [16:37:20] <cato_> ok, so how many parties are involved in this? users, miners, companies (did I miss any?). ideally, you'd somehow measure support from all parties, and only go ahead with the fork if all agree <-- miners have no say
12:27 < luke-jr> (except insofar as they are also users/businesses)
12:28 < gmaxwell> luke-jr: "which IMO we shouldn't". I'm having a hard time expressing how disagreeable this sounds to me.  This is squarly in the domain of manufacturing opposition where as far as we know it simply does not exist.  If this were a controversial proposal, I would agree that were a reasonable position that you could argue for.  But as far as I know, it simply isn't and has no reason to be.
12:30 < luke-jr> gmaxwell: even with a contentious softfork (segwit), users successfully switched to an alternate activation build; without contention, that's even more realistic
12:30 < luke-jr> (and even if it hadn't been proven to work, it would still be an ideal to strive for)
12:30 < gmaxwell> You would not say, "sorry, core should not fix the merkle tree malleability change, because it's a consensus change. Instead all the contributors should just forget that they are users of bitcoin too, and sit on their hands hoping some deus-ex-users manages to excercise technical decision making AFTER having subtracted all the people most competent to do it."
12:31 < luke-jr> gmaxwell: contributors make the alternate builds too
12:32 < luke-jr> bugfixes are clearly a different realm than improvements
12:32 < gmaxwell> That is not at all clear to me.
12:33 < luke-jr> O.o
12:33 < roconnor> Core merges in all sorts of improvements, HD wallets, descriptors, bech32 addresses, why not taproot?
12:33 < gmaxwell> As far as I know the change is not adverse to anyone's interest. It has no effect on people that don't use it, except they need to upgrade-- which is also true of 'bug fixes'.
12:34 < luke-jr> roconnor: that's after it activates, not in order to activate
12:34 < gmaxwell> If not for the fact that script is limited in various ways, it wouldn't even be a consensus change at all-- it would just be some new script-code.
12:34 < luke-jr> err gmaxwell^
12:34 < gmaxwell> luke-jr: whats after it activates?
12:34 < luke-jr> roconnor: non-consensus improvements are something that developers can make a decision on alone
12:35 < luke-jr> gmaxwell: nobody needs to upgrade until the softfork is active
12:35 < gmaxwell> luke-jr: people can always make a decision alone on anything.
12:35 < gmaxwell> luke-jr: same with some consensus bugfix.
12:35 < roconnor> Core developers should be willing to merge in any software that they think and if they think that Bitcore Core gets better by merging in taproot and/or merging in taproot activation, then they should do it.
12:36 < roconnor> I really don't see the big deal about merging in activation of harmless consensus changes.
12:37 < luke-jr> it's the same reason historically softforks went into .1 releases, so users could make the decision without external pressures
12:38 < luke-jr> putting activations into Core also makes Core into a gatekeeper of sorts
12:38 < luke-jr> especially with the monopoly it has today
12:38 < gmaxwell> The reason there was a lot more so that we wouldn't have users stuck not enforcing it (or even opposing it) just because upgrading was a burden.
12:39 < luke-jr> the current precedent is to activate with separate builds; where is the rationale to switch back?
12:39 < roconnor> There is nothing gatekeeperish about Core and merging consensus activation rules doesn't afect that.
12:40 < gmaxwell> luke-jr: I beg you, please don't do this. You are failing in king solomon's trial-- not because you greedily want the baby, but because you've convinced yourself that each person getting half a baby is fundimentally more fair.
12:40 < roconnor> what's this current precedent?
12:40 < luke-jr> gmaxwell: ⁇?
12:41 < luke-jr> gmaxwell: that implies it won't work, but it has already proven to work
12:41 < gmaxwell> roconnor: a fantasy story about segwit being activated by UASF.  Which to whatever limited extent has truth to it, was still the case of something with actual opposition.
12:41 < luke-jr> roconnor: Segwit was activated by people switching to "Bitcoin Core UASF" releases
12:42 < roconnor> luke-jr: At best it is unclear what happened, but I don't think it is fair to conculde that UASF activated Segwit.
12:42 < roconnor> And I don't think it has set a precident.
12:42 < luke-jr> roconnor: and yes, there is quite a bit of gatekeeping in Core, even aside from consensus changes.. lots of features rejected and removed because of certain Core devs' politics
12:42 < gmaxwell> That is extremely disputable. And to the extent that it's true, it's indirect. Only a extremely tiny number of users ran that software, the influence it had was not that software activating it, but rather people backing off from forking away that software.
12:42 < roconnor> All that we know is that for some reason miners all started signaling before the Segwit activation deadline and it was activated.
12:42 < roconnor> And we can only speculate about why that happened.
12:44 < luke-jr> it was clear in 2017
12:44 < roconnor> luke-jr: I don't think I would call that gatekeeping when anyone is free to fork Core software.  If it was gatekeeping then knots wouldn't exist.
12:44 < gmaxwell> I think it's more accurate to speculate that BIP91 reintroduced the threat of orphaning, and with that in place-- and it being made clear to miners benefiting from covert boosting that they couldn't prevent it forever--, miners stopped fucking around.
12:44 < jeremyrubin> I think the gatekeepering effect is interesting in that if we make it clear merging to Core is not a part of the process, then it makes it easier to understand what should happen when someone propose and upgrade. But right now because merge to core is important for an upgrade, then it puts maintainers in position to "decide"
12:45 < gmaxwell> luke-jr: no, you were saying it in 2017 and other people-- including me-- were saying that was as bizarre position then.
12:45 < jeremyrubin> I could imagine a world where we whittle down what "core" is to just be releases and "developers" to be the code, repo
12:45 < jeremyrubin> But I don't think we're presently in that world
12:45 < jeremyrubin> But it is what wumpus called for in '17
12:46 < jeremyrubin> https://github.com/bitcoin/bitcoin/pull/10417#issuecomment-302299372
12:46 < gmaxwell> Wumpus makes mistakes too.
12:47 < gmaxwell> Basically this kind of abdication and faux-neutrality allows the least reasonable people to seize control whenever they want to and have the most to gain from it.
12:48 < luke-jr> using the word "abdication" just proves the point, I think; it isn't devs' job/decision to simply make
12:48 < jeremyrubin> I'm just saying that it's a reasonable position for Luke to have relative to his experience and conversation in this thread. His effort was actively gate kept here, so you can't deny that. If we shouldn't model the future off of the past (learning from past errors), then I think it's a different discussion.
12:49 < luke-jr> we are not kings deciding protocol rules; not-deciding is not abdication
12:49 < gmaxwell> In the case of some kind of genuine controversy it can be reasonable to step back, but to just apply it for any arbritary non-controversial desicions is just a gigantic lie.  It's a lie that other decisions aren't important, and its a lie that the decisions can't be made without the people best informed to contribute to them,  it's a lie that the community doesn't (rightfully!) someone
12:49 < gmaxwell> depend on trusting people with an established track record, at least over matters that they're otherwise neutral on.
12:49 < roconnor> But taproot is only changing the behaviour of unallocated Segwit V1 scripts.  Why shouldn't Core make these descisions with they make other decisions about HD wallets, sets, and address formats, things that have even a greater impact that the taproot consensus changes?
12:50 < jeremyrubin> I generally agree with gmaxwell on the above tho fwiw. There's a "big hammer" and you don't need to use it all the time.
12:50 < gmaxwell> luke-jr: IT IS EVERYONES JOB TO BE TRUTHFUL ABOUT WHAT THEY THINK IS BEST.
12:50 < luke-jr> gmaxwell: yes, and we can all express that
12:50 < gmaxwell> as it stands right now, we don't know of any credible reason to not activate taproot. If we did, my position would change.
12:50 < ja> roconnor: "with they make" ?
12:51 < jeremyrubin> when they make
12:51 < jeremyrubin> roconnor: and the reason is for those things you can plausibly run an old node version with those
12:51 < jeremyrubin> but with a soft fork it's not great to not be up to date
12:52 < luke-jr> roconnor: those other things are merely a question of developers' time, not network consensus everyone must agree on
12:52 < jeremyrubin> I think a good example is Suhas's recent change got a BIP
12:52 < jeremyrubin> didn't require versionbits, but should be communicated as it effects practically running a network node
12:53 < ja> jeremyrubin, your argument would extend to new address formats too, right?
12:53 < jeremyrubin> roconnor: https://github.com/bitcoin/bips/blob/master/bip-0339.mediawiki
12:53 < gmaxwell> like for example, of taproot contained BLS signatures that required 100x longer to validate. Then people could credibly oppose it on the basis of the resource usage increase, and the possibility that better BLS parameters might come around next week turning the old ones into all technical debt.  Such an addition might still be a good one in my opinion, but it might be better to take a weaker
12:53 < gmaxwell> position on it because there is legitimately a tradeoff.
12:53 < jeremyrubin> ja: not at all, network has no concept of addresses, just RPCs
12:53 < gmaxwell> jeremyrubin: lots of changes get BIPs, but having a bip documents it for interoperability, it's not a request for permission to implement it.
12:54 < luke-jr> gmaxwell: even more ideal might be to prompt users upon upgrade with an explanation and support vs oppose decision, but what happens when Core maintainers decide they don't want to give users that choice (as effectively with BIP148)?
12:54 < gmaxwell> No "permission to implement" is sought or desired for most BIPped changes in bitcoin core.
12:54 < jeremyrubin> gmaxwell: that's my point sort of? Changes which impact interop have a different process than things you can just happily run an old node and not upgrade
12:54 < roconnor> luke-jr: not merging activiation into Core is a recipe for disconsensus.  It doesn't make any sense to do so.
12:55 < gmaxwell> luke-jr: Promoting people to support or oppose implies we think that opposing it is anything but insane and even unethical.  I think absent a credible opposition it is actually unethical to oppose taproot, because generally how I manage my coins is not your business at all.
12:55 < luke-jr> roconnor: not any more than light wallets are, at worst
12:55 < gmaxwell> jeremyrubin: okay, yes they have a different process but the process doesn't usually involve seeking anyone's approval.
12:56 < luke-jr> roconnor: also, you're implying people won't use the correct build
12:56 < gmaxwell> Peter Rizun / BU as well as Tom Zander tried to oppose compact blocks, and they were told, essentially "fuck you". (actually, I believe they were *actually* told "fuck you").
12:56 < luke-jr> gmaxwell: "unethical to oppose taproot" is an argument I haven't considered
12:57 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
12:57 < gmaxwell> luke-jr: To be clear, if someone cropped up saying  "hey, this will make my node implementation 1000x more complex and its not worth it" I would consider that opposition wrong, but not unethical.  But currently no one is arguing that.
12:58 < gmaxwell> (and if they did, I think they'd rightfully lose users and reputation because it would be such a lame argument)
12:58 < luke-jr> hmm
12:58 < luke-jr> "I don't think this has had sufficient review" perhaps?
12:58 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
12:58 < gmaxwell> Yes, that would also be an ethical argument, but it's one that invites either fixes or a debate that shows its wrong.
12:59 < gmaxwell> (wrong and maybe just a cover for an unethical argument, like "I don't want bitcoin users to have more efficient multisig in their own transactions")
12:59 < luke-jr> gmaxwell: maybe a page like the Segwit summary would be ideal
12:59 < luke-jr> and "Reasons to oppose: Nobody has raised any" :P
13:00 < gmaxwell> haha yes, perhaps, though god knows. People love to fill in a blank space.
13:00 < luke-jr> gmaxwell: yes, I do wonder sometimes if some of the ossification movement is just altcoins trying to prevent Bitcoin from competing..
13:01 < gmaxwell> We should keep in mind that not all changes are equal. Just like you see no issue in treating bug fixes differently, a script addition that has no widespread effect except that people choose to use it, and doesn't increase resource usage...  is a lot more like a bugfix than some other possible consensus change.
13:02 < luke-jr> yes, I did look explicitly for Taproot making the weight problem worse, and concluded it looked like it shouldn't in any case
13:02 < ja> i don't understand why ethics needs to be brought up? isn't it a recipe for disagreement if you need to talk about ethical values before you can take a stance on taproot?
13:02 < gmaxwell> we should generally be pretty liberal with those, with the primary arguments related to its complexity/review or that its design isn't complete and would slow/block the creation of a better alternative.
13:02 < jeremyrubin> luke-jr: I think it pertains more to marketing materials from certain people about how good bitcoin already is. If it's so great, why change anything? It's sort of like being on a rocket but not wanting to detach the booster stage because "we're already halfway there why mess with it now".
13:02 < luke-jr> ja: the discussion is more about to what degree users should explicitly opt-in or opt-out
13:02 < gmaxwell> ja: because lukes argument that it should prompt users to support or oppose is an ethically driven position.
13:03 < luke-jr> jeremyrubin: "some"
13:03 < gmaxwell> And my argument is that it's not neutral, because opposing -- absent certian reasons for the opposition-- isn't very ethical.
13:03 < jeremyrubin> luke-jr: I've engaged with people who are hardcore ossification beleivers and I don't think that it is generally the case that they are anything other than confused about how mature bitcoin is
13:04 < jeremyrubin> but yes, "some". probably an element to that too
13:04 < gmaxwell> Political/ethical neutrality is an illusion in any case,  the mere existance of bitcoin is extremely political.  At best we can do is hope to stick to the core political kernel and not expand the politics of bitcoins existance too much such that it alienates users with diverse beliefs.
13:06 < gmaxwell> jeremyrubin: fortunately, taproot doesn't change what bitcoin is fundimentally. Why change the successful formula would apply to something that changed the headline description of bitcoin.
13:07 < gmaxwell> like in principle in bitcoin the user decides the conditions under which their own coins get spent.  Optimizing that to increase their flexibility or lower its cost or whatnot is usually not an extremely fundimental shift.
13:08 < ja> gmaxwell: do you think taproot activation would benefit from an explicit explanation of why taproot is building upon values that bitcoin already has?
13:10 < gmaxwell> Perhaps. Just also I think that care should be taken to not accidentally manufacture dissent.  People depend a lot on implicit signaling.  If you imagine some public policy that litterally *everyone* supports (like I dunno, air being free to breath) and stand up a bunch of authorities basically debating imaginary opponents, so you will find *real* opponents and a small faction of people
13:10 < gmaxwell> supporting them.
13:11 < gmaxwell> It's important to give airtime to real disagreements, but it's dangerous to try to be so "fair" that you actually manufacture disgreements ex-nihilo out of the quantum foam.
13:23 < brg444> very much agree on the above. conviction is honorable and to an extent this false neutrality is quite patronizing
13:25 < gmaxwell> to be clear, I think the effort at neutrality luke puts out is genuinely motivated, but it comes across as false (becuase I think it actually is accidentally false, not because it's intended to be false but because the hoped for neutrality is pretty much a logical and pratical impossibility)
13:31 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined ##taproot-activation
13:39 -!- brg444 [be2ec812@pc-18-200-46-190.cm.vtr.net] has quit [Remote host closed the connection]
13:41 < cato_> 22:03 < gmaxwell> haha yes, perhaps, though god knows. People love to fill in a blank space.
13:43 < cato_> weak objections and FUD should be easily addressed. or do you think soliciting objections might be enough to give people the idea there's something to object?
13:45 < gmaxwell> I think an initial correctly targeted "Hey, developer list are you aware of any substantial objections that bother you personally" would be harmless.
13:45 < gmaxwell> Thats different from a communication with the general public.
13:47 -!- rdymac [uid31665@gateway/web/irccloud.com/x-mtgojwnzssoqnbvb] has quit [Quit: Connection closed for inactivity]
13:48 < gmaxwell> Fortunately, through the power of artifical intelligence, I can predict the future, according to the 1.5 billion entry GPT2, a likely continuation of the following text "Taproot is one of the most significant Bitcoin Improvement Proposals (BIP) written in recent years. In a nutshell, it aims to enable privacy and flexibility for Bitcoin smart contracts. The major opposition to taproot is:"
13:48 < gmaxwell> is --
13:48 < gmaxwell> 1. The lack of a clear roadmap for the implementation. The idea for taproot was first mentioned at the Consensus conference in 2015. However, the roadmap for implementing taproot into Bitcoin was not made clear at that time and the project has not produced any tangible outcome of its intentions. Thus, the project should not be considered as a BIP and is not a "real" Bitcoin Improvement
13:48 < gmaxwell> Proposal.
13:48 < gmaxwell> 2. The lack of testing and review. The code in question has not been reviewed by developers and the code of the project has not undergone any serious review. The code in question is not well tested, and so the risks associated with the implementation may well have not been considered as far as technical issues. Moreover, the code in question has not received the required security reviews. As
13:48 < gmaxwell> such, the code in question may not be robust enough for its purpose.
13:48 < gmaxwell> 3. Lack of consensus on the implementation. As mentioned above, the idea for taproot was introduced at the 2015 Consensus conference in 2015. However, the roadmap for implementing taproot into Bitcoin did not materialize in the time frame proposed. The project remains in "in development" phase and it has not yet reached the critical threshold that it is to become a "real" Bitcoin Improvement
13:48 < gmaxwell> Proposal (BIP). This may also not be considered as a BIP and is not considered as a real Bitcoin Improvement Proposal.
13:48 < gmaxwell> 4. The lack of the necessary resources. The project has no dedicated resources dedicated to its implementation. It has been reported that the team is currently only in its fourth iteration and it may also not be able to maintain the codebase
13:48 < gmaxwell> -----
13:52 -!- justinmoon [~quassel@157.245.122.126] has joined ##taproot-activation
13:52 -!- gambpang [~gambpang@unaffiliated/gambpang] has joined ##taproot-activation
13:53 < gmaxwell> (I think it's interesting to consult the AI to get an idea of what a spherical idiot might think)
14:03 < felixweis> moneyball, thank you 🙏 for creating this channel. reading these discussion alone is worth more sats than 10 soft-fork activations.
14:08 < ja> gmaxwell: it is interesting, but is it really productive? worst case, people are discouraged from commenting because they don't wanna be dismissed as arguing no better than AI. what is the best case? it the humor really worth it?
14:10 < jonatack> felixweis: +1
14:11 < gmaxwell> ja: well it's amusing, but it's actually interesting because there are decent odds that, knowing nothing but what you'd know from reading a bunch of articles,  these might be the sort of questions you want clearly answered.
14:11 < gmaxwell> that there is a clear roadmap, testing and review, that there is broadspread consensus, and the resources exist to see it through.
14:12 < jeremyrubin> curious what you get for the inverse
14:12 < jeremyrubin> Taproot is one of the most significant Bitcoin Improvement Proposals (BIP) written in recent years. In a nutshell, it aims to enable privacy and flexibility for Bitcoin smart contracts. The major argument for taproot is
14:12 < gmaxwell> jeremyrubin: one sec.
14:14 < gmaxwell> my expirence is that it will mostly repeat the prompt for that kind of input, but lemme try.
14:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
14:14 < gmaxwell> (basically, GPT2's idea is that when we write support for something we just repeat the description of the thing we're supporting)
14:14 < jeremyrubin> Ah maybe flip it to a negative
14:15 < jeremyrubin> Like a bunch of bad things, and then "nevertheless, we should add taproot because
14:15 < gmaxwell> yes, it will do that better.
14:16 < gmaxwell> (there is kind of an art to getting good output from GPT2)
14:16 < gmaxwell> (also its handicapped here because it doesn't actually know what taproot is)
14:16 < gmaxwell> and arguments against something can be general, but arguments for something are always specific.
14:16 < jeremyrubin> yeah
14:17 < jeremyrubin> that's what I was going to point out
14:17 < jeremyrubin> kinda illustrates how easy fudding is
14:17 < gmaxwell> I'm generating a couple outputs.
14:18 < roconnor> wait was that text above really written by an AI?
14:18 < felixweis> why not answer concerns from GPT-2 with an argument inversed prompt by GPT-3?
14:19 < gmaxwell> Too bad GPT-3 isn't openly available.
14:19 < gmaxwell> roconnor: yes sir, it was the FIRST non-human selected output too.
14:19 < roconnor> what was it trained on?
14:19 < felixweis> pipe the output into a bunch of medium posts and call it a day
14:19 < gmaxwell> roconnor: Everything ever posted to reddit which achieved a score of >3.
14:19 < gmaxwell> er >=3.
14:19 < gmaxwell> plus wikipedia, IIRC.
14:20 < midnight> does that mean I don't have to argue with people on reddit anymore
14:20 < luke-jr> lol
14:20 < roconnor> *LOL* I tought it sounds a lot like what I would read on reddit.
14:20 < gmaxwell> To be fair, I've been playing with this for a long time and I've gotten pretty good at writing prompts that generate useful output.
14:20 < roconnor> That's quite remarkable.
14:20 < gmaxwell> roconnor: IIRC it knows who you are from IRC logs.
14:20 < felixweis> i finally understand why you're spending so much time on !(r/bitcoin).
14:21 < roconnor> gmaxwell: has it mentioned me by name?
14:21 < luke-jr> gmaxwell: shouldn't it know what Taproot is then?
14:21 < gmaxwell> roconnor: yeah, I've seen it generate fake IRC logs with you in them.
14:21 < jeremyrubin> gmaxwell: can you change the prompt to "roconnor opposes taproot because"
14:21 < luke-jr> lol @ fake IRC logs
14:21 < gmaxwell> Here is some more opposition, https://0bin.net/paste/MMZZH2HDfPMKVF3P#E5BUUOVAiA1oAEecyrdlnPCVX3o7dzLMUzqAbJPsH91  I like the letter from Mike Hearn.. they're not actually as good as the very first output.
14:22 < jeremyrubin> I'm curious if it will latch on to roconnor and produce roconnor like objections, or if they stay general
14:22 -!- ja [janus@anubis.0x90.dk] has left ##taproot-activation []
14:22  * luke-jr peers at https://github.com/bitcoin/bitcoin/pull/6265
14:22 < gmaxwell> Here are arguments for it https://0bin.net/paste/pwMZ4yoRUDF0NX2k#uayVkSn+eQ4xj5wLTiRuaD+Nwq1ci9gKutZ1YVLde8z  -- as I predicted it's mostly just reiterating the description of 'taproot'.
14:23 < gmaxwell> jeremyrubin: it sometimes knows people talk about particular things, but it's pretty limited.
14:23 < jeremyrubin> "The most recent version of Bitcoin Core has support for taproot. This can be easily verified by running git clone git@github.com:taproot/taproot.git in a Bitcoin Core project folder and checking that it is running." this is great
14:24 < luke-jr> jeremyrubin: I got a 404 :p
14:25 < luke-jr> gmaxwell: can we get it to review the code?
14:25 < gmaxwell> I haven't figure out how to prompt it to write code reviews yet.
14:26 -!- wraithm [~wraithm@unaffiliated/wraithm] has joined ##taproot-activation
14:26 < gmaxwell> probably doing anythign useful there is beyond gpt2, more likely gpt3 would be useful.
14:26 < gmaxwell> sometimes it's just useful to hear what people sound like, divorced from the coloration of actually making sense.
14:27 < gmaxwell> like it was eye opening to me that gpt2 thinks that arguments in favor of things are mostly just repeating the description of the thing. I think that is a valid criticism of how people often argue for things.
14:27 < gmaxwell> it's more obviously a bad approach when the machine does it, because its dumb. :)
14:28 < gmaxwell> aside,
14:28 < gmaxwell> "Roconnor opposes taproot because there is no way to determine the current state of a contract's ledger or who created it."
14:28 < jeremyrubin> not sure but now I am opposed to taproot
14:28 < gmaxwell> which does sound like a restatement of an Roconnor objection, but I doubt it's actually demonstrating knowing who he is. it may only know him in the context of irc logs.
14:28 < jeremyrubin> sounds bad
14:29 < felixweis> this guy is against GPT-4 activation: https://www.gwern.net/GPT-3
14:30 < emzy> When will AI write code?
14:30 < roconnor> When I read gwerns article, I'm worried that has been genrated by GPT.  I mean look at it:
14:31 < roconnor> "GPT-3, however, is not merely a quantitative tweak yielding “GPT-2 but better”—it is qualitatively different, exhibiting eerie runtime learning capabilities allowing even the raw model, with zero finetuning, to “meta-learn” many textual tasks purely by example or instruction."
14:31 < roconnor> I don't know, is that real text or AI generated text.  I cannot tell anymore.
14:31 < felixweis> turing test passed
14:32 < felixweis> emzy, already happening https://twitter.com/sharifshameem/status/1282676454690451457
14:33 < instagibbs> tech q: I don't actually see anywhere where "ext_flag" value for taproot is actually defined(seems to be 0 from code) and tapscript's value seems to only be mentioned in bip341's footnotes?
14:33 < emzy> WOW
14:34 < instagibbs> ^ someone clue me in please
14:34 < jeremyrubin> gmax is generating taproot fud with gpt-2
14:34 < jeremyrubin> it's pretty close to what fud looks like
14:35 < jeremyrubin> your question about ext_flag is better in ##taproot-bip-review
14:35 < jeremyrubin> (taproot's main author for example isn't even here)
14:36 < roconnor> instagibbs: From BIP-0342: "The leaf version is 0xc0 (i.e. the first byte of the last witness element after removing the optional annex is 0xc0 or 0xc1), marking it as a tapscript spend."
14:38 < gmaxwell> imaginary conversation between luke-jr and roconnor, https://0bin.net/paste/e0ZE4IrWjxGHkFtv#4LCaBJP93pEUh3va-rGgcjm54THuCct0gwHg/E6/zFR  (not really that interesting, but if you havent seen much output like this it might amuse you)
14:42 < felixweis> on the internet, nobody knows you're GPT-2
14:44 < luke-jr> [21:28:52] <jeremyrubin> not sure but now I am opposed to taproot <-- lol
14:44 < roconnor> " it's really important to get BIPs implemented and implemented quickly"
14:47 < luke-jr> gmaxwell: I like that I join just as the conversation ends
14:47 < luke-jr> roconnor: can you email bitcoin-dev about this?
14:48 < roconnor> luke-jr: i'll send a message to bitcoin-dev about this later tonight or the next day, I'm gonna be on vacation for the next couple days
14:55 -!- fiatjaf [~fiatjaf@2804:7f2:2a83:3b59:ea40:f2ff:fe85:d2dc] has joined ##taproot-activation
14:58 < gmaxwell> I had more luck in getting it to argue for taproot by making it disagree with its prior objections: https://0bin.net/paste/hXrZg70kiUzjUigM#ykMx5msG2I73LZ3RD1FIgWDU3MNQQ0uIi4fHoV2ciL-
15:02 < luke-jr> roconnor: ok, please email bitcoin-dev about it
15:03 < luke-jr> gmaxwell: whoa, why didn't anyone tell me Taproot has no transaction fees⁈
15:03 < luke-jr> lol @ 3x Simplicity
15:11 < gmaxwell> yeah, unfortunately gpt2 is prone to repetition due to training artifacts. A lot of markuped text when converted to plaintext ends up with repetion... also quoted text.
15:11 < instagibbs> roconnor, oh, lol, ok. That's so indirect, but yes
15:12 < gmaxwell> it's exacerbated by top-k sampling, if you look at the raw model predictions, it often perfers to not repeat, but ranks the repeition highly then it gets chosen by chance.
15:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-activation
15:27 < gmaxwell> This set of prompts were extremely fruitful: https://0bin.net/paste/btUAJMUMoJPRZJHI#guvTrXODSHKIGODag1z-TegEdzZYTFrt7fvTCnlH/IL
15:27 < gmaxwell> "I used to be scared about taproot being added to bitcoin but I don't worry any more because I know you guys will do it, and you will make this awesome, amazing coin, because you are awesome guys!"
15:33 < roconnor> luke-jr: Um I'm actually not sure what you are refering to.  I was just joking around by cutting and pasting lines from our AI conversation.
15:33 < gmaxwell> roconnor: he was too. AFAIK
15:33 < roconnor> whew
15:33 < gmaxwell> lol
15:35 < gmaxwell> luke-jr: I wonder if we're not also mistakingly working off some cached challenges segwit had.  Like in segwit if the activation didn't activate, we couldn't easily start a second overlapping activation with different activation rules,  because of P2P interactions.  I think that doesn't apply at all for taproot-- segwit was extremely weird because it was a change that impacted P2P, block
15:35 < gmaxwell> creation, as well as consensus.
15:36 < gmaxwell> vs with taproot, it would be possible to activate on one set of criteria on one bip, and before that one has timed out, start another activation of it on another bit without breaking anything.
15:37 < roconnor> intersting.  We could start a bip9 style activation today and then while that is going spend the next 3 months debating the BIP 8 activation.
15:39 -!- slivera [~slivera@103.231.88.10] has joined ##taproot-activation
15:39 < gmaxwell> roconnor: or start a BIP9 activation, set the timeout-to-default-on for two years out,  and if its later decided this was a bad idea, softfork it out before it activates.
15:40 < gmaxwell> or later decided that two years was too long, do a new activation (which could even force triggering of the earlier onem when it activates)
15:41 < roconnor> Sorry when I said BIP-9 I meant BIP-8 with default-off.
15:41 < gmaxwell> ah. I'd give the same reply, instead of default off, it could be default on but with an inflated timeout time.
15:41 < roconnor> yes.
15:42 < gmaxwell> and then as people are more confident that users want it and have upgraded, supplant it with a shorter one that triggers the longer one too.
15:42 < roconnor> I don't think BlueMatt or anyone else wants MTP time over block height time.
15:43 < roconnor> I kinda think BlueMatt would perfer the default-off positions and if it is 2 years out and we are entertaining a second bit that would force activation of the first bit if we feel the need to, it probably doesn't matter if the default is on or off.
15:43 < gmaxwell> the idea that you can deactivate a default-activating proposal with another softfork isn't something I'd considered before you mentioned it.
15:44 < roconnor> and if being off makes people happer (but it has to be real people not imaginary people) then I guess that is fine.
15:44 < roconnor> *lol* I thought it was well-known that we could emergency soft fork out taproot in case of unexpected disaster.
15:44 < gmaxwell> I have a preference to default on just because it makes it unambigious that miners don't get to block it without a reason. (e.g. passively)
15:45 < gmaxwell> roconnor: I mean I *knew* it, but hadn't considered it as an activation management tool.
15:45 < gmaxwell> it makes default-on stuff more attractive to me.
15:45 < roconnor> I do too.  But I *think* BlueMatt doesn't like it for optical reasons that I don't quite understand.  I don't really want to argue for him ... although he isn't here right now to argue for himself.
15:46 < gmaxwell> I'll refrain from strawmanning his position.
15:46 < gmaxwell> ... so instead I'll have gpt2 strawman it.
15:47 < roconnor> *lol*
15:47 < roconnor> Still I think this layered activation may have some merit.
15:51 -!- slivera [~slivera@103.231.88.10] has quit [Quit: Leaving]
15:51 < gmaxwell> I am liking layered/nested more than sequential.
15:51 < gmaxwell> Sequential just has the potential of extremely long delays.
15:51 < gmaxwell> And while we should be patient and not expect things too quick, we should also be mindful of the cost of the delays.
15:52 < gmaxwell> If taproot takes an additional two years to activate, not because it's improving or being made more rugged, I think this will create substantial risks of its own.
15:56 -!- brg444 [uid207215@gateway/web/irccloud.com/x-vybllcbwpxngsqcu] has joined ##taproot-activation
16:05 -!- rdymac [uid31665@gateway/web/irccloud.com/x-jhjshgzomxfhhudn] has joined ##taproot-activation
16:06 < gmaxwell> I fed GPT2 our entire discussion and then asked virtual matt to summerize his position.
16:06 < gmaxwell> 01:20 < gmaxwell> BlueMatt: Please summarize your position.
16:06 < gmaxwell> 01:20 < BlueMatt> gmaxwell: ok, I'll give a long story of my thinking
16:06 < gmaxwell> 01:25 < BlueMatt> gmaxwell: here is my story
16:06 < gmaxwell> 01:25 < BlueMatt> taproot does *not* exist yet, it is just not yet implemented, so we do not know if people will accept it.
16:06 < gmaxwell> 01:26 < BlueMatt> if a few people start rejecting and it gets a few dozen people saying no, then it goes to a hardfork, and then a split.
16:07 < gmaxwell> 01:32 < gmaxwell> BlueMatt: I am not sure what is "not yet implemented" about. (it is a bit more complicated than that).
16:07 < gmaxwell> 01:35 < BlueMatt> I think you're making the mistake of thinking about a "fork" as a single thing, rather than a system change that includes things that happen after the fork, like users changing software
16:07 < gmaxwell> 01:35 < sipa> what's the difference? what does a split between two clients mean?
16:07 < gmaxwell> 01:37 < BlueMatt> sipa: they can only interact with each other
16:07 < gmaxwell> 01:37 < BlueMatt> if you don't understand what a fork is, you should read up.
16:08 < midnight> :-o
16:10 < real_or_random> Oo
16:13 < luke-jr> [22:33:36] <gmaxwell> roconnor: he was too. AFAIK <-- yes
16:14 < luke-jr> [22:37:32] <roconnor> intersting.  We could start a bip9 style activation today and then while that is going spend the next 3 months debating the BIP 8 activation. <-- that assumes BIP 9 is reasonable; it isn't
16:14 -!- kallewoof [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has joined ##taproot-activation
16:14 < luke-jr> hmm, maybe I should finish reading before sending replies
16:15 < luke-jr> [22:41:32] <gmaxwell> ah. I'd give the same reply, instead of default off, it could be default on but with an inflated timeout time. <-- I think BIP 8 might be broken for changing the timeout time, currently
16:16 < gmaxwell> luke-jr: can't I make a BIP8 with a shorter timeout that requires sinaling the longer timeout one?
16:16 < luke-jr> gmaxwell: yes, but that's ugly and indicates a failure of BIP8 IMO
16:16 < luke-jr> gmaxwell: no reason BIP8 can't be changed to make this just work cleanly
16:17 < luke-jr> (I suspect the suggestions aj sent me that I haven't fully reviewed yet, would do so)
16:17 < luke-jr> [23:06:54] <gmaxwell> 01:25 < BlueMatt> gmaxwell: here is my story <-- lol
16:17 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined ##taproot-activation
16:19 < jeremyrubin> did you see the BIP8 changes I suggested?
16:19 < jeremyrubin> https://github.com/bitcoin/bips/pull/944
16:20 < luke-jr> yes
16:20 < luke-jr> I think it doesn't make sense, but I am not sure yet.
16:21 < jeremyrubin> as in make sense why
16:22 < jeremyrubin> or technically broken
16:22 < luke-jr> the former
16:23 < gmaxwell> https://0bin.net/paste/o8BSsgUnLfYssmH-#YqOYsbFEMLHn1vKbittG0E0hDjb2NepP2TJC1FKU3IR < vitual sipa explains how to activate taproot
16:24 < luke-jr> "if X, the upgrade goes forward. if not, the upgrade goes through anyway" lolwut
16:25 < jeremyrubin> luke-jr: the devs vote to override the user negative vote
16:25 < jeremyrubin> but if users positive vote no dev vote is needed
16:25 < luke-jr> k tyrant sipa
16:25 < instagibbs> bringing cyber-sipa into this conversation is probably a crime against the AI
16:25 < jeremyrubin> I mean it's technically sound, perhaps not socially
16:26 < jeremyrubin> Like you could definitely use this governance process for ethereum
16:26 < gmaxwell> jeremyrubin: where do you think GPT2 learned this approach?
16:27 < gmaxwell> "I learned it from you, ETHER, I learned it from you!"
16:27 < gmaxwell> In Search Results
16:27 < gmaxwell> Web results
16:27 < gmaxwell> oops
16:27 < jeremyrubin> Does GPT give you some sort of attention based explainability?
16:28 < jeremyrubin> What posts it is drawing from?
16:29 < jeremyrubin> I'm sure openai has some dev tools for that but probably not out of the box with the public model
16:31 < gmaxwell> It's not explicable like that outside of training, because it doesn't even have access to the source material at runtime.
16:31 < gmaxwell> In Alastair Reynolds' Revelation Space novels there are two kinds of artificial minds. Alpha-type which are created from uploaded brain scans, and beta-type which are created by running a passive recorder of all your externally visible actions for decades and then conditioning a machine to imitate you.  There is some interesting discussion of the nature of the beta-type intelligence.
16:33 < luke-jr> I wonder if it's a mistake to mention timeframes like 1 year in BIP8; people seem to be interpreting it as part of the BIP
16:33 < luke-jr> rather than just suggestions
16:39 < jeremyrubin> It says suggestion at the top, but then uses "should" in a lot places which sounds like there is a reason. Maybe adding a few more "is recommendeds" can dilute it, or you can put absurd amounts of time in
16:40 < jeremyrubin> In particular I personally think startheight is too short from release without earliestheight
16:41 < jeremyrubin> release to live on the network potnetially taking just ~40 days seems aggressive
16:43 < gmaxwell> luke-jr: if you feel you need to keep an example in for drafting pruposes you could make it 100 years.
16:43 < gmaxwell> at least then if people take that number seriously it'll be funny.
16:44 < gmaxwell> or 6000 years.
16:45 < jeremyrubin> gmaxwell: good thing the times are height based
16:46 < luke-jr> lol
17:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
18:28 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined ##taproot-activation
18:28 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
18:29 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 240 seconds]
18:49 < gmaxwell> https://www.reddit.com/r/Bitcoin/comments/hqzp14/technical_the_path_to_taproot_activation/fy3mzvh/?context=3
19:05 -!- joerodgers [~joerodger@141.98.255.150] has quit [Read error: Connection reset by peer]
19:07 -!- joerodgers [~joerodger@45.83.220.165] has joined ##taproot-activation
19:07 -!- joerodgers1 [~Thunderbi@45.83.220.165] has joined ##taproot-activation
19:14 < roconnor> https://old.reddit.com/r/Bitcoin/comments/hqzp14/technical_the_path_to_taproot_activation/fy3mzvh/?context=3
19:17 -!- joerodgers [~joerodger@45.83.220.165] has quit [Remote host closed the connection]
19:17 -!- joerodgers1 is now known as joerodgers
19:17 -!- _joerodgers [~joerodger@45.83.220.165] has joined ##taproot-activation
19:26 -!- _joerodgers [~joerodger@45.83.220.165] has quit [Ping timeout: 256 seconds]
19:27 -!- _joerodgers [~joerodger@45.83.220.165] has joined ##taproot-activation
20:24 -!- benthecarman_ [~benthecar@185.45.15.222] has joined ##taproot-activation
20:25 -!- benthecarman [~benthecar@185.195.16.181] has quit [Read error: Connection reset by peer]
20:27 -!- _joerodgers [~joerodger@45.83.220.165] has quit [Ping timeout: 256 seconds]
20:27 -!- _joerodgers [~joerodger@45.83.220.165] has joined ##taproot-activation
21:28 -!- cato_ [~alec@gateway/tor-sasl/alec] has quit [Remote host closed the connection]
21:48 -!- joerodgers1 [~Thunderbi@45.83.220.165] has joined ##taproot-activation
21:48 -!- _joerodgers [~joerodger@45.83.220.165] has quit [Read error: Connection reset by peer]
21:48 -!- joerodgers [~Thunderbi@45.83.220.165] has quit [Read error: Connection reset by peer]
21:48 -!- joerodgers1 is now known as joerodgers
21:49 -!- _joerodgers [~joerodger@45.83.220.165] has joined ##taproot-activation
21:53 -!- cato_ [~alec@gateway/tor-sasl/alec] has joined ##taproot-activation
22:15 -!- brg444 [uid207215@gateway/web/irccloud.com/x-vybllcbwpxngsqcu] has quit [Quit: Connection closed for inactivity]
23:11 -!- slivera [~slivera@103.231.88.27] has joined ##taproot-activation
23:24 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
23:25 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
--- Log closed Wed Jul 15 00:00:21 2020