David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-21 📝 Original message:On 21.04.2022 04:58, Matt ...
📅 Original date posted:2022-04-21
📝 Original message:On 21.04.2022 04:58, Matt Corallo wrote:
> On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:
>> The main criticisms I'm aware of against CTV seem to be along the
>> following lines:
>>
>> 1. Usage, either:
>> a. It won't receive significant real-world usage, or
>> b. It will be used but we'll end up using something better later
>> 2. An unused CTV will need to be supported forever, creating extra
>> maintenance
>> burden, increasing security surface, and making it harder to
>> evaluate later
>> consensus change proposals due to their interactions with CTV
>
> Also "is this even the way we should be going about covenants?"
I consider this to be a version of point 1b above. If we find a better
way for going about covenants, then we'll activate that and let CTV
automatically be retired at the end of its five years.
If you still think your point is separate from point 1b, I would
appreciate you helping me understand.
> the Bitcoin technical community (or at least those interested in
> working on covenants) doesn't even remotely show any signs of
> consensus around any concrete proposal,
This is also my assessment: neither CTV nor any other proposal currently
has enough support to warrant a permanent change to the consensus rules.
My question to the list was whether we could use a transitory soft fork
as a method for collecting real-world usage data about proposals. E.g.,
a consensus change proposal could proceed along the following idealized
path:
- Idea (individual or small group)
- Publication (probably to this list)
- Draft specification and implementation
- Riskless testing (integration tests, signet(s), testnet, etc)
- Money-at-stake testing (availability on a pegged sidechain, an altcoin
similar to Bitcoin, or in Bitcoin via a transitory soft fork)
- Permanent consensus change
> talking about a "way forward for CTV" or activating CTV or coming up
> with some way of shoving it into Bitcoin at this stage [...] sets
> incredibly poor precedent for
> how we think about changes to Bitcoin and maintaining Bitcoin's
> culture of security and careful design.
How should we think about changes to Bitcoin and maintaining its culture
of security and careful design? My post suggested a generalized way we
could evaluate proposed consensus changes for real-world demand,
allowing us to settle what I see as the most contended part of the CTV
proposal. That feels to me like legitimate engineering and social
consensus building. What would be your preferred alternatives?
(For the record, my preferred alternative for years has been to add the
technically trivial opcodes OP_CAT and OP_CHECKSIGFROMSTACK, see what
covenant-y things people build with them, and then consider proposals to
optimize the onchain usage of those covenant-y things. Alas, this seems
to fall afoul of the concerns held by some people about recursive
covenants.)
> I'm gobsmacked that the conversation has reached this point, and am
> even more surprised that the response from the Bitcoin (technical)
> community hasn't been a more resounding and complete rejection of this
> narrative.
If the only choices are to support activation of BIP119 CTV at this time
or to reject it, I would currently side with rejection. But I would
prefer over both of those options to find a third way that doesn't
compromise safety or long-term maintainability and which gives us the
data about CTV (or other covenant-related constructions) to see whether
the concerns described above in 1a and 1b are actually non-issues.
I see one of those third ways as the testing on the CTV signet described
in a contemporaneous thread on this list.[1] Other third ways would be
trying CTV on sidechains or altcoins, or perhaps allowing CTV to be
temporarily used on Bitcoin as proposed in this thread. Is there
interest in working on those alternatives, or is the only path forward
an argument over attempting activation of CTV?
Thanks,
-Dave
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020234.html
📝 Original message:On 21.04.2022 04:58, Matt Corallo wrote:
> On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:
>> The main criticisms I'm aware of against CTV seem to be along the
>> following lines:
>>
>> 1. Usage, either:
>> a. It won't receive significant real-world usage, or
>> b. It will be used but we'll end up using something better later
>> 2. An unused CTV will need to be supported forever, creating extra
>> maintenance
>> burden, increasing security surface, and making it harder to
>> evaluate later
>> consensus change proposals due to their interactions with CTV
>
> Also "is this even the way we should be going about covenants?"
I consider this to be a version of point 1b above. If we find a better
way for going about covenants, then we'll activate that and let CTV
automatically be retired at the end of its five years.
If you still think your point is separate from point 1b, I would
appreciate you helping me understand.
> the Bitcoin technical community (or at least those interested in
> working on covenants) doesn't even remotely show any signs of
> consensus around any concrete proposal,
This is also my assessment: neither CTV nor any other proposal currently
has enough support to warrant a permanent change to the consensus rules.
My question to the list was whether we could use a transitory soft fork
as a method for collecting real-world usage data about proposals. E.g.,
a consensus change proposal could proceed along the following idealized
path:
- Idea (individual or small group)
- Publication (probably to this list)
- Draft specification and implementation
- Riskless testing (integration tests, signet(s), testnet, etc)
- Money-at-stake testing (availability on a pegged sidechain, an altcoin
similar to Bitcoin, or in Bitcoin via a transitory soft fork)
- Permanent consensus change
> talking about a "way forward for CTV" or activating CTV or coming up
> with some way of shoving it into Bitcoin at this stage [...] sets
> incredibly poor precedent for
> how we think about changes to Bitcoin and maintaining Bitcoin's
> culture of security and careful design.
How should we think about changes to Bitcoin and maintaining its culture
of security and careful design? My post suggested a generalized way we
could evaluate proposed consensus changes for real-world demand,
allowing us to settle what I see as the most contended part of the CTV
proposal. That feels to me like legitimate engineering and social
consensus building. What would be your preferred alternatives?
(For the record, my preferred alternative for years has been to add the
technically trivial opcodes OP_CAT and OP_CHECKSIGFROMSTACK, see what
covenant-y things people build with them, and then consider proposals to
optimize the onchain usage of those covenant-y things. Alas, this seems
to fall afoul of the concerns held by some people about recursive
covenants.)
> I'm gobsmacked that the conversation has reached this point, and am
> even more surprised that the response from the Bitcoin (technical)
> community hasn't been a more resounding and complete rejection of this
> narrative.
If the only choices are to support activation of BIP119 CTV at this time
or to reject it, I would currently side with rejection. But I would
prefer over both of those options to find a third way that doesn't
compromise safety or long-term maintainability and which gives us the
data about CTV (or other covenant-related constructions) to see whether
the concerns described above in 1a and 1b are actually non-issues.
I see one of those third ways as the testing on the CTV signet described
in a contemporaneous thread on this list.[1] Other third ways would be
trying CTV on sidechains or altcoins, or perhaps allowing CTV to be
temporarily used on Bitcoin as proposed in this thread. Is there
interest in working on those alternatives, or is the only path forward
an argument over attempting activation of CTV?
Thanks,
-Dave
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020234.html