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