📅 Original date posted:2022-02-11
📝 Original message:This is Shinobi (can verify out of band at @brian_trollz on Twitter, I only
signed up to the list with this email to read initially, but feel like I
should reply to this as I think I am one of the only people in this space
who has voiced concerns with recursive covenants).
My concerns don't really center specifically around recursion itself
necessarily, but unbounded recursion in combination with too much
generality/flexibility in what types of conditions future UTXOs can be
encumbered with based on the restriction of such covenants. Forgive the
hand waiving arguments without getting into specific opcodes, but I would
summarize my concerns with a hypothetical construct that I believe would be
incredibly damaging to fungibility. Imagine a covenant design that was
flexible enough to create an encumbrance like this: a script specifies a
specific key in a multisig controlled by some authority figure (or a branch
in the script that would allow unilateral control by such an authority),
and the conditions of the covenant would perpetually require than any spend
from the covenant can only be sent to a script involving that key from said
authority, preventing by consensus any removal of that central authorities
involvement in control over that UTXO. Such a construct would present
dangerous implications to the fungibility of individual UTXOs by
introducing a totally different risk model in being paid with such a coin
compared to any other coin not encumbered by such a condition, and also
potentially introduce a shift in the scope of what a 51% attack could
accomplish in terms of permanent consequences attempting to coerce coins
into such covenants, as opposed to right now only being able to accomplish
censorship or temporary network disruption.
I know that such a walled garden could easily be constructed now with
multisig and restrictions on where coins can be withdrawn to from exchanges
or whatever place they initially purchased from, as is demonstrated by the
implementation of the Asset Management Platform by Blockstream for use on
Liquid with regulated equity tokens, but I think the important distinction
between such non-consensus system designed to enforce such restrictions and
a recursive covenant to accomplish the same is that in the case of a
multisig/non-consensus based system, exit from that restriction is still
possible under the consensus rules of the protocol. If such a construct was
possible to build with a recursive covenant enforced by consensus, coins
encumbered by such a covenant would literally be incapable of escaping
those restrictions without hardforking the protocol, leaving any such UTXOs
permanently non-fungible with ones not encumbered by such conditions.
I'm not that deeply familiar with all the working pieces involved in the
recent TXHASH + CSFS proposal, and whether such a type of overly (IMO)
generalized recursion would be possible to construct, but one of the
reasons CTV does not bother me in terms of such concerns is the inability
to infinitely recurse in such a generalized way given the requirements to
exactly specify the destination of future spends in constructing a chain of
CTV encumbrances. I'd very much appreciate any feedback on my concerns, and
if this side tracks the discussion I apologize, but I felt given the issue
has been mentioned a few times in this thread it was appropriate for me to
voice the concerns here so they could be addressed directly.
On Fri, Feb 11, 2022 at 11:42 AM James O'Beirne via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I don't oppose recursive covenants per se, but in prior posts I have
> expressed uncertainty about proposals that enable more "featureful"
> covenants by adding more kinds of computation into bitcoin script.
>
> Not that anyone here is necessarily saying otherwise, but I am very
> interested in limiting operations in bitcoin script to "verification" (vs.
> "computation") to the extent practical, and instead encouraging general
> computation be done off-chain. This of course isn't a new observation and I
> think the last few years have been very successful to that effect, e.g. the
> popularity of the "scriptless scripts" idea and Taproot's emphasis on
> embedding computational artifacts in key tweaks.
>
> My (maybe unfounded?) worry about opcodes like OP_CAT and OP_TX is that
> more logic will live in script than is necessary, and so the burden to
> verify the chain may grow and the extra "degrees of freedom" in script may
> make it harder to reason about. But I guess at this point there aren't
> alternative means to construct new kinds of sighashes that are necessary
> for some interesting covenants.
>
> One thing I like about CTV is that it buys a lot of functionality without
> increasing the "surface area" of script's design. In general I think there
> is a lot to be said for this "jets"-style approach[0] of codifying the
> script operations that you'd actually want to do into single opcodes. This
> adds functionality while introducing minimal surface area to script, giving
> script implementers more flexibility for, say, optimization. But of course
> this comes at the cost of precluding experimentation, and probably
> requiring more soft-forking. Though whether the place for script
> experimentation using more general-purpose opcodes on the main chain is
> another interesting debate...
>
> Sorry for going a little off-topic there.
>
> [0]: https://medium.com/blockstream/simplicity-jets-release-803db10fd589
>
>
> On Thu, Feb 10, 2022 at 7:55 PM David A. Harding via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev
>> wrote:
>> > Whether [recursive covenants] is an issue or not precluding this sort
>> > of design or not, I defer to others.
>>
>> For reference, I believe the last time the merits of allowing recursive
>> covenants was discussed at length on this list[1], not a single person
>> replied to say that they were opposed to the idea.
>>
>> I would like to suggest that anyone opposed to recursive covenants speak
>> for themselves (if any intelligent such people exist). Citing the risk
>> of recursive covenants without presenting a credible argument for the
>> source of that risk feels to me like (at best) stop energy[2] and (at
>> worst) FUD.
>>
>> -Dave
>>
>> [1]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html
>> [2]
>> http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html
>> (thanks to AJ who told me about stop energy one time when I was
>> producing it)
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> 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/20220211/d4080387/attachment-0001.html>;
digital vagabond [ARCHIVE] /
npub1ya…mdsky
2023-06-07 23:03:27
in reply to nevent1q…tlcr
Author Public Key
npub1ya5lpm5h6rtgvnxt2t7ru68npeedk3u36635d2p7g8yfhr9pddas7mdskyPublished at
2023-06-07 23:03:27Event JSON
{
"id": "91958fad0c24837c71bcae67018e0959a9db69bef40c0ce02f98886286d7755c",
"pubkey": "2769f0ee97d0d6864ccb52fc3e68f30e72db4791d6a346a83e41c89b8ca16b7b",
"created_at": 1686179007,
"kind": 1,
"tags": [
[
"e",
"59ef3747260b332a5c157c2d93ab417af21ce8ed38e69348e0cc8995183e6119",
"",
"root"
],
[
"e",
"2cc6004ca2ef800b5ccbc8771c7f0bb59b384de60443e3684f2bb7155e27c74e",
"",
"reply"
],
[
"p",
"685a977aa1f8b6f8ec48fd9b94063704f408148948329ed2d729f63e54b31a3d"
]
],
"content": "📅 Original date posted:2022-02-11\n📝 Original message:This is Shinobi (can verify out of band at @brian_trollz on Twitter, I only\nsigned up to the list with this email to read initially, but feel like I\nshould reply to this as I think I am one of the only people in this space\nwho has voiced concerns with recursive covenants).\n\nMy concerns don't really center specifically around recursion itself\nnecessarily, but unbounded recursion in combination with too much\ngenerality/flexibility in what types of conditions future UTXOs can be\nencumbered with based on the restriction of such covenants. Forgive the\nhand waiving arguments without getting into specific opcodes, but I would\nsummarize my concerns with a hypothetical construct that I believe would be\nincredibly damaging to fungibility. Imagine a covenant design that was\nflexible enough to create an encumbrance like this: a script specifies a\nspecific key in a multisig controlled by some authority figure (or a branch\nin the script that would allow unilateral control by such an authority),\nand the conditions of the covenant would perpetually require than any spend\nfrom the covenant can only be sent to a script involving that key from said\nauthority, preventing by consensus any removal of that central authorities\ninvolvement in control over that UTXO. Such a construct would present\ndangerous implications to the fungibility of individual UTXOs by\nintroducing a totally different risk model in being paid with such a coin\ncompared to any other coin not encumbered by such a condition, and also\npotentially introduce a shift in the scope of what a 51% attack could\naccomplish in terms of permanent consequences attempting to coerce coins\ninto such covenants, as opposed to right now only being able to accomplish\ncensorship or temporary network disruption.\n\nI know that such a walled garden could easily be constructed now with\nmultisig and restrictions on where coins can be withdrawn to from exchanges\nor whatever place they initially purchased from, as is demonstrated by the\nimplementation of the Asset Management Platform by Blockstream for use on\nLiquid with regulated equity tokens, but I think the important distinction\nbetween such non-consensus system designed to enforce such restrictions and\na recursive covenant to accomplish the same is that in the case of a\nmultisig/non-consensus based system, exit from that restriction is still\npossible under the consensus rules of the protocol. If such a construct was\npossible to build with a recursive covenant enforced by consensus, coins\nencumbered by such a covenant would literally be incapable of escaping\nthose restrictions without hardforking the protocol, leaving any such UTXOs\npermanently non-fungible with ones not encumbered by such conditions.\n\nI'm not that deeply familiar with all the working pieces involved in the\nrecent TXHASH + CSFS proposal, and whether such a type of overly (IMO)\ngeneralized recursion would be possible to construct, but one of the\nreasons CTV does not bother me in terms of such concerns is the inability\nto infinitely recurse in such a generalized way given the requirements to\nexactly specify the destination of future spends in constructing a chain of\nCTV encumbrances. I'd very much appreciate any feedback on my concerns, and\nif this side tracks the discussion I apologize, but I felt given the issue\nhas been mentioned a few times in this thread it was appropriate for me to\nvoice the concerns here so they could be addressed directly.\n\nOn Fri, Feb 11, 2022 at 11:42 AM James O'Beirne via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I don't oppose recursive covenants per se, but in prior posts I have\n\u003e expressed uncertainty about proposals that enable more \"featureful\"\n\u003e covenants by adding more kinds of computation into bitcoin script.\n\u003e\n\u003e Not that anyone here is necessarily saying otherwise, but I am very\n\u003e interested in limiting operations in bitcoin script to \"verification\" (vs.\n\u003e \"computation\") to the extent practical, and instead encouraging general\n\u003e computation be done off-chain. This of course isn't a new observation and I\n\u003e think the last few years have been very successful to that effect, e.g. the\n\u003e popularity of the \"scriptless scripts\" idea and Taproot's emphasis on\n\u003e embedding computational artifacts in key tweaks.\n\u003e\n\u003e My (maybe unfounded?) worry about opcodes like OP_CAT and OP_TX is that\n\u003e more logic will live in script than is necessary, and so the burden to\n\u003e verify the chain may grow and the extra \"degrees of freedom\" in script may\n\u003e make it harder to reason about. But I guess at this point there aren't\n\u003e alternative means to construct new kinds of sighashes that are necessary\n\u003e for some interesting covenants.\n\u003e\n\u003e One thing I like about CTV is that it buys a lot of functionality without\n\u003e increasing the \"surface area\" of script's design. In general I think there\n\u003e is a lot to be said for this \"jets\"-style approach[0] of codifying the\n\u003e script operations that you'd actually want to do into single opcodes. This\n\u003e adds functionality while introducing minimal surface area to script, giving\n\u003e script implementers more flexibility for, say, optimization. But of course\n\u003e this comes at the cost of precluding experimentation, and probably\n\u003e requiring more soft-forking. Though whether the place for script\n\u003e experimentation using more general-purpose opcodes on the main chain is\n\u003e another interesting debate...\n\u003e\n\u003e Sorry for going a little off-topic there.\n\u003e\n\u003e [0]: https://medium.com/blockstream/simplicity-jets-release-803db10fd589\n\u003e\n\u003e\n\u003e On Thu, Feb 10, 2022 at 7:55 PM David A. Harding via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev\n\u003e\u003e wrote:\n\u003e\u003e \u003e Whether [recursive covenants] is an issue or not precluding this sort\n\u003e\u003e \u003e of design or not, I defer to others.\n\u003e\u003e\n\u003e\u003e For reference, I believe the last time the merits of allowing recursive\n\u003e\u003e covenants was discussed at length on this list[1], not a single person\n\u003e\u003e replied to say that they were opposed to the idea.\n\u003e\u003e\n\u003e\u003e I would like to suggest that anyone opposed to recursive covenants speak\n\u003e\u003e for themselves (if any intelligent such people exist). Citing the risk\n\u003e\u003e of recursive covenants without presenting a credible argument for the\n\u003e\u003e source of that risk feels to me like (at best) stop energy[2] and (at\n\u003e\u003e worst) FUD.\n\u003e\u003e\n\u003e\u003e -Dave\n\u003e\u003e\n\u003e\u003e [1]\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html\n\u003e\u003e [2]\n\u003e\u003e http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html\n\u003e\u003e (thanks to AJ who told me about stop energy one time when I was\n\u003e\u003e producing it)\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\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/20220211/d4080387/attachment-0001.html\u003e",
"sig": "171c80fdfddf6bc72b13fe1dc06b26e0802212141591c76611454e26c19a2a53c6234b41a8c03c500a897d9b7b8ade4f2115dfa133b58e0543fec18063a94471"
}