📅 Original date posted:2022-03-11
📝 Original message:On Fri, Mar 11, 2022, 00:12 Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Thu., Mar. 10, 2022, 08:04 Jorge Timón via bitcoin-dev, <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>>
>> 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.
>>
>
> For goodness sake Jorge, enough with the persecution complex.
>
Thanks for answering.
As the person who initially proposed the Speedy Trial deployment design, I
> can say it was designed to take in account those concerns raised by luke-jr
> and the "no-miner-veto" faction. I also listened to the
> "devs-do-not-decide" faction and the "no-divegent-consensus-rules" faction
> and their concerns.
>
That's great, but it still doesn't take into account my concerns. I'm not
part of any of those "factions". I guess I'm part of the "yes-user-veto"
faction. I know, I know, we don't matter because the "no-divergent-rules"
"faction" matters too much for us to be listened.
The "no-miner-veto" concerns are, to an extent, addressed by the short
> timeline of Speedy Trial. No more waiting 2 years on the miners dragging
> their feet. If ST fails to active then we are back where we started with
> at most a few weeks lost. And those weeks aren't really lost if they would
> have been wasted away anyways trying to find broad consensus on another
> deployment mechanism.
>
> I get that you don't like the design of Speedy Trial. You may even object
> that it fails to really address your concerns by leaving open how to follow
> up a failed Speedy Trial deployment. But regardless of how you feel, I
> believe I did meaningfully address the those miner-veto concerns and other
> people agree with me.
>
> If you are so concerned about listening to legitimate criticism, maybe you
> can design a new deployment mechanism that addresses the concerns of the
> "devs-do-not-decide" faction and the "no-divegent-consensus-rules"
> faction. Or do you feel that their concerns are illegitimate? Maybe, by
> sheer coincidence, all people you disagree with have illegitimate concerns
> while only your concerns are legitimate.
>
I talked about this. But the "no-divergent-rules" faction doesn't like it,
so we can pretend we have listened to this "faction" and addressed all its
concerns, I guess.
Or perhaps it's just "prosectution complex", but, hey, what do I know about
psychology?
A major contender to the Speedy Trial design at the time was to mandate
> eventual forced signalling, championed by luke-jr. It turns out that, at
> the time of that proposal, a large amount of hash power simply did not have
> the firmware required to support signalling. That activation proposal
> never got broad consensus, and rightly so, because in retrospect we see
> that the design might have risked knocking a significant fraction of mining
> power offline if it had been deployed. Imagine if the firmware couldn't be
> quickly updated or imagine if the problem had been hardware related.
>
Yes, I like this solution too, with a little caveat: an easy mechanism for
users to actively oppose a proposal.
Luke alao talked about this.
If users oppose, they should use activation as a trigger to fork out of the
network by invalidating the block that produces activation.
The bad scenario here is that miners want to deploy something but users
don't want to.
"But that may lead to a fork". Yeah, I know.
I hope imagining a scenario in which developers propose something that most
miners accept but some users reject is not taboo.
Some of these discussions started at the time of segwit activation. Yes,
segwit, not taproot.
As for mark, he wasn't talking about activation, but quantum computing
concerns. Perhaps those have been "addressed"?
I just don't know where.
_______________________________________________
> 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/20220311/98eb3c55/attachment.html>;
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 23:06:01
in reply to nevent1q…25rk
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 23:06:01Event JSON
{
"id": "e2c8dc80bc0057323ca740ad3f5bdc60d8d40374317455b86832f9ead34e4ef5",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686179161,
"kind": 1,
"tags": [
[
"e",
"a5af5e39047c2302ef2c813ca29b2c17152d49444d282becfeb36106acf5ee47",
"",
"root"
],
[
"e",
"22ffabca57ee3901c8700de1d104d055e970c85bac9a79903a493a23a7df2a28",
"",
"reply"
],
[
"p",
"7866e39300a17990d3d88285e5fe24e019b0dfdd93c220c6d02f67095af5f70e"
]
],
"content": "📅 Original date posted:2022-03-11\n📝 Original message:On Fri, Mar 11, 2022, 00:12 Russell O'Connor via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e On Thu., Mar. 10, 2022, 08:04 Jorge Timón via bitcoin-dev, \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e You're right, we shouldn't get personal. We shouldn't ignore feedback\n\u003e\u003e from me, mark friedenbach or luke just because of who it comes from.\n\u003e\u003e\n\u003e\n\u003e For goodness sake Jorge, enough with the persecution complex.\n\u003e\n\nThanks for answering.\n\nAs the person who initially proposed the Speedy Trial deployment design, I\n\u003e can say it was designed to take in account those concerns raised by luke-jr\n\u003e and the \"no-miner-veto\" faction. I also listened to the\n\u003e \"devs-do-not-decide\" faction and the \"no-divegent-consensus-rules\" faction\n\u003e and their concerns.\n\u003e\n\nThat's great, but it still doesn't take into account my concerns. I'm not\npart of any of those \"factions\". I guess I'm part of the \"yes-user-veto\"\nfaction. I know, I know, we don't matter because the \"no-divergent-rules\"\n\"faction\" matters too much for us to be listened.\n\n\n\nThe \"no-miner-veto\" concerns are, to an extent, addressed by the short\n\u003e timeline of Speedy Trial. No more waiting 2 years on the miners dragging\n\u003e their feet. If ST fails to active then we are back where we started with\n\u003e at most a few weeks lost. And those weeks aren't really lost if they would\n\u003e have been wasted away anyways trying to find broad consensus on another\n\u003e deployment mechanism.\n\u003e\n\u003e I get that you don't like the design of Speedy Trial. You may even object\n\u003e that it fails to really address your concerns by leaving open how to follow\n\u003e up a failed Speedy Trial deployment. But regardless of how you feel, I\n\u003e believe I did meaningfully address the those miner-veto concerns and other\n\u003e people agree with me.\n\u003e\n\u003e If you are so concerned about listening to legitimate criticism, maybe you\n\u003e can design a new deployment mechanism that addresses the concerns of the\n\u003e \"devs-do-not-decide\" faction and the \"no-divegent-consensus-rules\"\n\u003e faction. Or do you feel that their concerns are illegitimate? Maybe, by\n\u003e sheer coincidence, all people you disagree with have illegitimate concerns\n\u003e while only your concerns are legitimate.\n\u003e\n\nI talked about this. But the \"no-divergent-rules\" faction doesn't like it,\nso we can pretend we have listened to this \"faction\" and addressed all its\nconcerns, I guess.\nOr perhaps it's just \"prosectution complex\", but, hey, what do I know about\npsychology?\n\nA major contender to the Speedy Trial design at the time was to mandate\n\u003e eventual forced signalling, championed by luke-jr. It turns out that, at\n\u003e the time of that proposal, a large amount of hash power simply did not have\n\u003e the firmware required to support signalling. That activation proposal\n\u003e never got broad consensus, and rightly so, because in retrospect we see\n\u003e that the design might have risked knocking a significant fraction of mining\n\u003e power offline if it had been deployed. Imagine if the firmware couldn't be\n\u003e quickly updated or imagine if the problem had been hardware related.\n\u003e\n\nYes, I like this solution too, with a little caveat: an easy mechanism for\nusers to actively oppose a proposal.\nLuke alao talked about this.\nIf users oppose, they should use activation as a trigger to fork out of the\nnetwork by invalidating the block that produces activation.\nThe bad scenario here is that miners want to deploy something but users\ndon't want to.\n\"But that may lead to a fork\". Yeah, I know.\nI hope imagining a scenario in which developers propose something that most\nminers accept but some users reject is not taboo.\n\nSome of these discussions started at the time of segwit activation. Yes,\nsegwit, not taproot.\n\nAs for mark, he wasn't talking about activation, but quantum computing\nconcerns. Perhaps those have been \"addressed\"?\nI just don't know where.\n\n_______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220311/98eb3c55/attachment.html\u003e",
"sig": "ec5715d171d463c248d5f3da7eb39331cde6ddb6e9757d5e859c4ee066f153867fdf3a76ad3f546e9c72daef338c62e2ffeace1a808b5e4e76c870cc531e2094"
}