So, to be clear, you didn't design speedy trial "to make everyone unhappy" as Ryan claims, no?
That's a really strange claim on his part.
When the grace period for slower activation after lock in was added, I don't think it was added to make me or people like me who dislike that proposal unhappy. On the contrary, I think the goal was precisely to address some of our concerns.
But it doesn't address them all, as I've tried to explain other times.
I truly think you wanted to make everyone happy with speedy trial, but you didn't do it, sorry.
I know it' not a lack of capacity because you did impressive and genius things like simplicity.
But despite your best intentions and your great capacity, I still think speedy trial is a very bad proposal because you got the analysis wrong.
Let me reiterate that this is not attack against you, but only against one of your ideas.
Sorry if I sounded sarcastic, but I was trying to be sarcastic with ryan, not with you.


On Fri, May 6, 2022 at 8:24 PM Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Fri, May 6, 2022 at 2:01 PM Jorge Timón via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Russell O'Connor wrote the definitive explanation for how ST arose in
the consensus process and how it was designed to make everyone
unhappy.  It's a great explanation of what we went through last year.

  https://r6.ca/blog/20210615T191422Z.html

    "On Building Consensus and Speedy Trial"

    on | 2021-06-15T19:14:22Z
    by | Russell O'Connor

That's a lot of text, are you sure he said in there he designed speedy trial to make everyone unhappy?
Well, if we're still talking about it, that proves that it failed at its own design criterion of failing fast.


> Speedy Trial’s design is not based on any sort of activation philosophy about failing fast. 
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev