📅 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
David A. Harding [ARCHIVE] /
npub16d…x4wrd
2023-06-07 23:07:35
in reply to nevent1q…l09e
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-07 23:07:35Event JSON
{
"id": "ae08d4fbd067627f9c03560ca171833ba1db154abd6a2e1eb4e240dce9566277",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686179255,
"kind": 1,
"tags": [
[
"e",
"3199d7e373413debbd60986222963e0a7995231a8bea9719310656b98185e004",
"",
"root"
],
[
"e",
"1f25f6bd150bf29d84ee63208ad60ccec568db1fb15ae256f6ab4c174fb493cf",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2022-04-21\n📝 Original message:On 21.04.2022 04:58, Matt Corallo wrote:\n\u003e On 4/20/22 6:04 PM, David A. Harding via bitcoin-dev wrote:\n\u003e\u003e The main criticisms I'm aware of against CTV seem to be along the \n\u003e\u003e following lines:\n\u003e\u003e \n\u003e\u003e 1. Usage, either:\n\u003e\u003e a. It won't receive significant real-world usage, or\n\u003e\u003e b. It will be used but we'll end up using something better later\n\u003e\u003e 2. An unused CTV will need to be supported forever, creating extra \n\u003e\u003e maintenance\n\u003e\u003e burden, increasing security surface, and making it harder to \n\u003e\u003e evaluate later\n\u003e\u003e consensus change proposals due to their interactions with CTV\n\u003e \n\u003e Also \"is this even the way we should be going about covenants?\"\n\nI consider this to be a version of point 1b above. If we find a better \nway for going about covenants, then we'll activate that and let CTV \nautomatically be retired at the end of its five years.\n\nIf you still think your point is separate from point 1b, I would \nappreciate you helping me understand.\n\n\u003e the Bitcoin technical community (or at least those interested in\n\u003e working on covenants) doesn't even remotely show any signs of\n\u003e consensus around any concrete proposal,\n\nThis is also my assessment: neither CTV nor any other proposal currently \nhas enough support to warrant a permanent change to the consensus rules. \n My question to the list was whether we could use a transitory soft fork \nas a method for collecting real-world usage data about proposals. E.g., \na consensus change proposal could proceed along the following idealized \npath:\n\n- Idea (individual or small group)\n- Publication (probably to this list)\n- Draft specification and implementation\n- Riskless testing (integration tests, signet(s), testnet, etc)\n- Money-at-stake testing (availability on a pegged sidechain, an altcoin \nsimilar to Bitcoin, or in Bitcoin via a transitory soft fork)\n- Permanent consensus change\n\n\u003e talking about a \"way forward for CTV\" or activating CTV or coming up\n\u003e with some way of shoving it into Bitcoin at this stage [...] sets \n\u003e incredibly poor precedent for\n\u003e how we think about changes to Bitcoin and maintaining Bitcoin's\n\u003e culture of security and careful design.\n\nHow should we think about changes to Bitcoin and maintaining its culture \nof security and careful design? My post suggested a generalized way we \ncould evaluate proposed consensus changes for real-world demand, \nallowing us to settle what I see as the most contended part of the CTV \nproposal. That feels to me like legitimate engineering and social \nconsensus building. What would be your preferred alternatives?\n\n(For the record, my preferred alternative for years has been to add the \ntechnically trivial opcodes OP_CAT and OP_CHECKSIGFROMSTACK, see what \ncovenant-y things people build with them, and then consider proposals to \noptimize the onchain usage of those covenant-y things. Alas, this seems \nto fall afoul of the concerns held by some people about recursive \ncovenants.)\n\n\u003e I'm gobsmacked that the conversation has reached this point, and am\n\u003e even more surprised that the response from the Bitcoin (technical)\n\u003e community hasn't been a more resounding and complete rejection of this\n\u003e narrative.\n\nIf the only choices are to support activation of BIP119 CTV at this time \nor to reject it, I would currently side with rejection. But I would \nprefer over both of those options to find a third way that doesn't \ncompromise safety or long-term maintainability and which gives us the \ndata about CTV (or other covenant-related constructions) to see whether \nthe concerns described above in 1a and 1b are actually non-issues.\n\nI see one of those third ways as the testing on the CTV signet described \nin a contemporaneous thread on this list.[1] Other third ways would be \ntrying CTV on sidechains or altcoins, or perhaps allowing CTV to be \ntemporarily used on Bitcoin as proposed in this thread. Is there \ninterest in working on those alternatives, or is the only path forward \nan argument over attempting activation of CTV?\n\nThanks,\n\n-Dave\n\n[1] \nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020234.html",
"sig": "d3c06172a2766eac4f43a116e6dd2f825cb34a15efc4ec67c4d9559fcb0ce524b4f4b5863547fade93cf593ba72616b25acf77701256309583c16826e0193c32"
}