On Wed, Mar 9, 2022, 14:14 Michael Folkson <michaelfolk...@protonmail.com> wrote:
> Hi Jorge > > > Since this has meetings like taproot, it seems it's going to end up > being added in bitcoin core no matter what. > > Anyone can set up a IRC channel, anyone can organize a IRC meeting, anyone > can announce meetings on the mailing list. Just because an individual is > enthusiastic for a soft fork proposal does not imply it has community > consensus or that it is likely to be merged into Core in the short term or > long term. It is true that other soft fork proposal authors/contributors > are not taking the approach Jeremy is taking and are instead working > quietly in the background. I prefer the latter approach so soon after > Taproot activation but I look forward to hearing about the progress made on > other proposals in due course. > I hope you're right and not every proposal that gets to have a meeting gets deployed. > Should we start the conversation on how to resist it when that happens? > We should talk more about activation mechanisms and how users should be > able to actively resist them more. > > I can only speak for myself but if activation was being pursued for a soft > fork that didn't have community consensus I would seek to join you in an > effort to resist that activation. Taproot (pre-activation discussion) set a > strong precedent in terms of community outreach and patiently building > community consensus over many years. If that precedent was thrown out I > think we are in danger of creating the chaos that most of us would seek to > avoid. You are free to start whatever conversation you want but personally > until Jeremy or whoever else embarks on an activation attempt I'd rather > forget about activation discussions for a while. > I strongly disagree taproot set a strong precedent in terms of listening to criticism and looking for consensus. Lots of legitimate criticisms seemed to be simply ignored. I really think it set a bad preference, even if taproot as deployed is good, which I'm not sure about. > What is ST? If it may be a reason to oppose CTV, why not talk about it > more explicitly so that others can understand the criticisms? > > ST is short for Speedy Trial, the activation mechanism used for Taproot. I > have implored people on many occasions now to not mix discussion of a soft > fork proposal with discussion of an activation mechanism. Those discussions > can happen in parallel but they are entirely independent topics of > discussion. Mixing them is misleading at best and manipulative at worst. > Thanks. Yes, those topics were ignored before "let's focus on the proposal first" and afterwards "let's just deploy this and we can discuss this in more detail for the next proposal". And I thonk lots of valid criticism was ignored and disregarded. > It seems that criticism isn't really that welcomed and is just explained > away. > Perhaps it is just my subjective perception. Sometimes it feels we're > going from "don't trust, verify" to "just trust jeremy rubin", i hope this > is really just my subjective perception. Because I think it would be really > bad that we started to blindly trust people like that, and specially jeremy. > > I think we should generally avoid getting personal on this mailing list. > However, although I agree that Jeremy has done some things in the past that > have been over-exuberant to put it mildly, as long as he listens to > community feedback and doesn't try to force through a contentious soft fork > earlier than the community is comfortable with I think his work can add > material value to the future soft fork discussion. I entirely agree that we > can't get into a situation where any one individual can push through a soft > fork without getting community consensus and deep technical review from as > many qualified people as possible. That can take a long time (the demands > on long term contributors' time are vast) and hence anyone without serious > levels of patience should probably exclusively work on sidechains, altcoins > etc (or non-consensus changes in Bitcoin) rather than Bitcoin consensus > changes. > You're right, we shouldn't get personal. We shouldn't ignore feedback from me, mark friedenbach or luke just because of who it comes from. I don't think jeremy listens to feedback, judging from taproot activation discussions, I felt very much ignores by him and others. Luke was usually ignored. Mark criticisms on taproot, not the activation itself, seemed to be ignored as well. I mean, if somebody refuted his concerns somewhere, I missed it. But even if I believe jremey has malicious intentions and doesn't listen to the community, you're still right, we shouldn't get personal. I shoud assume the same malevolent intentions I assume jeremy has from everyone else. Thanks > Michael > > -- > Michael Folkson > Email: michaelfolkson at protonmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > ------- Original Message ------- > On Wednesday, March 9th, 2022 at 11:02 AM, Jorge Timón via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Since this has meetings like taproot, it seems it's going to end up being > added in bitcoin core no matter what. > > Should we start the conversation on how to resist it when that happens? > We should talk more about activation mechanisms and how users should be > able to actively resist them more. > > > On Tue, Mar 8, 2022, 03:32 Jeremy Rubin via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> * Tuesday, March 8th. >> >> I think Noon PT == 8pm UTC? >> >> but dont trust me i cant even tell what day is what. >> -- >> @JeremyRubin <https://twitter.com/JeremyRubin> >> >> >> On Mon, Mar 7, 2022 at 6:50 PM Jeremy Rubin <jeremy.l.ru...@gmail.com> >> wrote: >> >>> Hi all, >>> >>> There will be a CTV meeting tomorrow at noon PT. Agenda below: >>> >>> 1) Sapio Taproot Support Update / Request for Review (20 Minutes) >>> - Experimental support for Taproot merged on master >>> https://github.com/sapio-lang/sapio >>> 2) Transaction Sponsoring v.s CPFP/RBF (20 Minutes) >>> - >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019879.html >>> - >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html >>> 3) Jamesob's Non-Recursive Vaults Post (20 minutes) >>> - >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020067.html >>> 4) What the heck is everyone talking about on the mailing list all of >>> the sudden (30 minutes) >>> - EVICT, TLUV, FOLD, Lisp, OP_ANNEX, Drivechain Covenants, Jets, Etc >>> 5) Q&A (30 mins) >>> >>> Best, >>> >>> Jeremy >>> >>> >>> -- >>> @JeremyRubin <https://twitter.com/JeremyRubin> >>> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
