public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon•cc>
To: Michael Folkson <michaelfolkson@protonmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] CTV Meeting #5 Agenda (Tuesday, March 7th, 12:00 PT)
Date: Thu, 10 Mar 2022 11:41:52 +0000	[thread overview]
Message-ID: <CABm2gDrd7w3tNV3Q6GWv94-yhqyLQo3=VBwBCuEQAYoBS9apgg@mail.gmail.com> (raw)
In-Reply-To: <I_a_0rdZqMuOXDXURNAOP2671wKNOh2VRImdVbidm0vKIXSRwIdjSbzrpv-NkPUbSvkfi_JpP516-JFVQyGzrCiyv0UuK1ti8zHBQmqKOgc=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 7122 bytes --]

On Wed, Mar 9, 2022, 14:14 Michael Folkson <michaelfolkson@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.rubin@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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 18694 bytes --]

      reply	other threads:[~2022-03-10 11:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-08  2:50 Jeremy Rubin
2022-03-08  3:32 ` Jeremy Rubin
2022-03-09 11:02   ` Jorge Timón
2022-03-09 14:14     ` Michael Folkson
2022-03-10 11:41       ` Jorge Timón [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABm2gDrd7w3tNV3Q6GWv94-yhqyLQo3=VBwBCuEQAYoBS9apgg@mail.gmail.com' \
    --to=jtimon@jtimon$(echo .)cc \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=michaelfolkson@protonmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox