📅 Original date posted:2022-04-22
📝 Original message:If none of the alternative proposals have been developed as much as CTV, it
seems reasonable to interpret that as a lack of interest in those
alternative proposals themselves.
That should not be interpreted as lack of interest in covenants. Perhaps if
CTV didn't exist, we would have seen more progress on the alternatives.
It's entirely reasonable to assume that people who are interested in
covenants have put their energy and attention primarily behind CTV, and
that is why it is the furthest along. It shouldn't be a requisite to
improving Bitcoin that we have multiple, competing proposals for a
similar use case that have all been debated, implemented and tested before
we will be okay with integrating one of them. That may be the ideal, but it
shouldn't be a requirement.
If we can find consensus of moving forward with one of the proposals, and
there are concrete commitments to develop the alternatives over the next
few months, I would suggest that would be something worth waiting for. In
the absence of such consensus and commitments, the ask here is that CTV be
set aside in favor of an unlikely hypothetical.
Corey
On Fri, Apr 22, 2022 at 2:40 PM Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On 4/21/22 6:20 PM, David A. Harding wrote:
> > [Rearranging Matt's text in my reply so my nitpicks come last.]
> >
> > On 21.04.2022 13:02, Matt Corallo wrote:
> >> I agree, there is no universal best, probably. But is there a concrete
> >> listing of a number of use-cases and the different weights of things,
> >> plus flexibility especially around forward-looking designs?
> >
> > I'm sure we could make a nice list of covenant usecases, but I don't
> know how we would assign
> > reasonable objective weights to the different things purely through
> group foresight. I know I'm
> > skeptical about congestion control and enthusiastic about
> joinpools---but I've talked to developers
> > I respect who've had the opposite opinions from me about those things.
> The best way I know of to
> > reconcile our differing opinions is to see what real Bitcoin users
> actually pay for. But to do
> > that, I think they must have a way to use covenants in something like
> the production environment.
>
> To get good data for this kind of question you'd need much longer than
> five years, sadly. As we've
> seen over and over again in Bitcoin deploying very nontrivial things takes
> at least five years,
> often more. While vaults may be deployed relatively more quickly, the fact
> that we haven't seen
> (AFAIK) *anyone* deploy some of the key-deletion-based vault designs that
> have been floating around
> for some time is indication that even that probably wouldn't be deployed
> quickly.
>
> >> You're also writing off [...] a community of
> >> independent contributors who care about Bitcoin working together to
> >> make decisions on what is or isn't the "right way to go" [...]. Why are
> you
> >> suggesting its something that you "don't know how to do"?
> >
> > You said we should use the best design. I said the different designs
> optimize for different things,
> > so it's unlikely that there's an objective best. That implies to me
> that we either need to choose a
> > winner (yuck) or we need to implement more than one of the designs. In
> either of those cases,
> > choosing what to implement would benefit from data about how much the
> thing will be used and how
> > much users will pay for it in fees.
>
> I agree, there is no objective "best" design. But we can sill explore
> design tradeoffs and utility
> for different classes of covenants. I've seen relatively little of this so
> far, and from what I have
> seen its not been clear that CTV is really a good option, sadly.
>
>
> >> Again, you're writing off the real and nontrivial risk of doing a fork
> >> to begin with.
> >
> > I agree this risk exists and it isn't my intention to write it off---my
> OP did say "we [must be]
> > absolutely convinced CTV will have no negative effects on the holders or
> receivers of non-CTV
> > coins." I haven't been focusing on this in my replies because I think
> the other issues we've been
> > discussing are more significant. If we were to get everyone to agree to
> do a transitory soft fork,
> > I think the safety concerns related to a CTV soft fork could be
> mitigated the same way we've
> > mitigated them for previous soft forks: heaps of code review/testing and
> making sure a large part of
> > the active community supports the change.
>
> I'm not sure I made my point here clear - the nontrivial and real risk I
> was referring to was not
> avoidable with "moar code review" or "careful analysis to make sure the
> proposed fork doesn't cause
> damage". I mean issues that keep cropping up in many changes like "people
> start threatening to run a
> fork-causing client" or "some miners aren't validating blocks and end up
> creating a fork" or "some
> people forget to upgrade and follow such a fork" or..... there's lots and
> lots of risks to a doing a
> fork that come from the process and nature of forks, that have nothing to
> do with the actual details
> of the fork itself.
>
> Matt
> _______________________________________________
> 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/20220422/b344c2cb/attachment.html>;
Corey Haddad [ARCHIVE] /
npub1yv…u4zp6
2023-06-07 23:07:38
in reply to nevent1q…xlga
Author Public Key
npub1yvcp7ayqy5xa3qgtz9hj9hdn5c9shp6tuvrxu3tw99qj6dveq2csqu4zp6Published at
2023-06-07 23:07:38Event JSON
{
"id": "d4fcb56b63e6a83568ef55441dc228279c492968bbb21b336f006352180daa23",
"pubkey": "23301f7480250dd8810b116f22ddb3a60b0b874be3066e456e29412d359902b1",
"created_at": 1686179258,
"kind": 1,
"tags": [
[
"e",
"3199d7e373413debbd60986222963e0a7995231a8bea9719310656b98185e004",
"",
"root"
],
[
"e",
"85953592ff16b7eb1834092df07d8128474854d4168469e26ac40cb05caa8bed",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2022-04-22\n📝 Original message:If none of the alternative proposals have been developed as much as CTV, it\nseems reasonable to interpret that as a lack of interest in those\nalternative proposals themselves.\nThat should not be interpreted as lack of interest in covenants. Perhaps if\nCTV didn't exist, we would have seen more progress on the alternatives.\nIt's entirely reasonable to assume that people who are interested in\ncovenants have put their energy and attention primarily behind CTV, and\nthat is why it is the furthest along. It shouldn't be a requisite to\nimproving Bitcoin that we have multiple, competing proposals for a\nsimilar use case that have all been debated, implemented and tested before\nwe will be okay with integrating one of them. That may be the ideal, but it\nshouldn't be a requirement.\n\nIf we can find consensus of moving forward with one of the proposals, and\nthere are concrete commitments to develop the alternatives over the next\nfew months, I would suggest that would be something worth waiting for. In\nthe absence of such consensus and commitments, the ask here is that CTV be\nset aside in favor of an unlikely hypothetical.\n\nCorey\n\nOn Fri, Apr 22, 2022 at 2:40 PM Matt Corallo via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e\n\u003e On 4/21/22 6:20 PM, David A. Harding wrote:\n\u003e \u003e [Rearranging Matt's text in my reply so my nitpicks come last.]\n\u003e \u003e\n\u003e \u003e On 21.04.2022 13:02, Matt Corallo wrote:\n\u003e \u003e\u003e I agree, there is no universal best, probably. But is there a concrete\n\u003e \u003e\u003e listing of a number of use-cases and the different weights of things,\n\u003e \u003e\u003e plus flexibility especially around forward-looking designs?\n\u003e \u003e\n\u003e \u003e I'm sure we could make a nice list of covenant usecases, but I don't\n\u003e know how we would assign\n\u003e \u003e reasonable objective weights to the different things purely through\n\u003e group foresight. I know I'm\n\u003e \u003e skeptical about congestion control and enthusiastic about\n\u003e joinpools---but I've talked to developers\n\u003e \u003e I respect who've had the opposite opinions from me about those things.\n\u003e The best way I know of to\n\u003e \u003e reconcile our differing opinions is to see what real Bitcoin users\n\u003e actually pay for. But to do\n\u003e \u003e that, I think they must have a way to use covenants in something like\n\u003e the production environment.\n\u003e\n\u003e To get good data for this kind of question you'd need much longer than\n\u003e five years, sadly. As we've\n\u003e seen over and over again in Bitcoin deploying very nontrivial things takes\n\u003e at least five years,\n\u003e often more. While vaults may be deployed relatively more quickly, the fact\n\u003e that we haven't seen\n\u003e (AFAIK) *anyone* deploy some of the key-deletion-based vault designs that\n\u003e have been floating around\n\u003e for some time is indication that even that probably wouldn't be deployed\n\u003e quickly.\n\u003e\n\u003e \u003e\u003e You're also writing off [...] a community of\n\u003e \u003e\u003e independent contributors who care about Bitcoin working together to\n\u003e \u003e\u003e make decisions on what is or isn't the \"right way to go\" [...]. Why are\n\u003e you\n\u003e \u003e\u003e suggesting its something that you \"don't know how to do\"?\n\u003e \u003e\n\u003e \u003e You said we should use the best design. I said the different designs\n\u003e optimize for different things,\n\u003e \u003e so it's unlikely that there's an objective best. That implies to me\n\u003e that we either need to choose a\n\u003e \u003e winner (yuck) or we need to implement more than one of the designs. In\n\u003e either of those cases,\n\u003e \u003e choosing what to implement would benefit from data about how much the\n\u003e thing will be used and how\n\u003e \u003e much users will pay for it in fees.\n\u003e\n\u003e I agree, there is no objective \"best\" design. But we can sill explore\n\u003e design tradeoffs and utility\n\u003e for different classes of covenants. I've seen relatively little of this so\n\u003e far, and from what I have\n\u003e seen its not been clear that CTV is really a good option, sadly.\n\u003e\n\u003e\n\u003e \u003e\u003e Again, you're writing off the real and nontrivial risk of doing a fork\n\u003e \u003e\u003e to begin with.\n\u003e \u003e\n\u003e \u003e I agree this risk exists and it isn't my intention to write it off---my\n\u003e OP did say \"we [must be]\n\u003e \u003e absolutely convinced CTV will have no negative effects on the holders or\n\u003e receivers of non-CTV\n\u003e \u003e coins.\" I haven't been focusing on this in my replies because I think\n\u003e the other issues we've been\n\u003e \u003e discussing are more significant. If we were to get everyone to agree to\n\u003e do a transitory soft fork,\n\u003e \u003e I think the safety concerns related to a CTV soft fork could be\n\u003e mitigated the same way we've\n\u003e \u003e mitigated them for previous soft forks: heaps of code review/testing and\n\u003e making sure a large part of\n\u003e \u003e the active community supports the change.\n\u003e\n\u003e I'm not sure I made my point here clear - the nontrivial and real risk I\n\u003e was referring to was not\n\u003e avoidable with \"moar code review\" or \"careful analysis to make sure the\n\u003e proposed fork doesn't cause\n\u003e damage\". I mean issues that keep cropping up in many changes like \"people\n\u003e start threatening to run a\n\u003e fork-causing client\" or \"some miners aren't validating blocks and end up\n\u003e creating a fork\" or \"some\n\u003e people forget to upgrade and follow such a fork\" or..... there's lots and\n\u003e lots of risks to a doing a\n\u003e fork that come from the process and nature of forks, that have nothing to\n\u003e do with the actual details\n\u003e of the fork itself.\n\u003e\n\u003e Matt\n\u003e _______________________________________________\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/20220422/b344c2cb/attachment.html\u003e",
"sig": "e246c2b3649a7ef56b150d1fe60cad8bcb1d0d5d9bdda1c3c39544f1f409474812c39dfbf6664f42bd9f54c349ca4f034c8b6257ace2cbd1be58b577f7aade54"
}